Hi Heiko, > Hi Takahiro.Kuwano, > > On 13.10.26 03:20, [email protected] wrote: > > Hi Heiko, > > > >> Hi Takahiro.Kuwano, > >> > >> On 09.10.26 11:28, Heiko Schocher wrote: > >>> Hello Takahiro.Kuwano, > >>> > >>> just answer here, before I looked into the comments from Simon... > >>> > >>> On 09.10.26 10:29, [email protected] wrote: > >>>> Hi Heiko and Simon, > >>>> > >>>>> Hi Heiko, > >>>>> > >>>>> On 2026-10-04T04:06:44, Heiko Schocher <[email protected]> wrote: > >>>>>> mtd: add driver for the Microchip 23LCV1024 SPI SRAM > >>>>>> > >>>>>> The 23LCV1024 is a 1 Mbit serial SRAM with battery backup, sitting on > >>>>>> an SPI bus and used as non volatile scratch storage. Register it as an > >>>>>> MTD device of type MTD_RAM, so the mtd command reaches it. > >>>>>> > >>>>>> The device powers up in byte operation, where every command carries > >>>>>> exactly one data byte. Select sequential operation once during probe, > >>>>> > >>>>> Just to check, is this right? My understanding is that the > >>>>> 23LC1024/23LCV1024 data sheet gives sequential mode (01) as the MODE > >>>>> register default; byte mode is the default only on the older 23K256. > >>>>> The Linux mchp23k256 driver never writes the MODE register. Setting it > >>>>> explicitly is still a fine defensive step, since something else could > >>>>> have changed the mode and the part keeps it while on battery. Please > >>>>> can you reword the commit message and the comment in spi_ram_probe() > >>>>> to match? > >>>>> > >>>>>> so that a read or a write of any length is served by a single command > >>>>>> and the bus is claimed once per transfer. > >>>>>> > >>>>>> Writing needs no erase. The driver therefore implements no erase > >>>>>> operation and says MTD_NO_ERASE in the MTD flags. > >>>>>> > >>>>>> Signed-off-by: Stefan Bigler <[email protected]> > >>>>>> Signed-off-by: Heiko Schocher <[email protected]> > >>>>>> > >>>>>> MAINTAINERS | 5 ++ > >>>>>> configs/sandbox_defconfig | 1 + > >>>>>> drivers/mtd/Kconfig | 14 +++ > >>>>>> drivers/mtd/Makefile | 1 + > >>>>>> drivers/mtd/spi_ram.c | 222 > >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++ > >>>>>> 5 files changed, 243 insertions(+) > >>>>> > >>>>>> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig > >>>>>> @@ -194,6 +194,20 @@ config ALTERA_QSPI > >>>>>> +config SPI_RAM > >>>>>> + bool "Microchip 23LCV1024 SPI SRAM" > >>>>>> + depends on DM_SPI && DM_MTD > >>>>> > >>>>> SPI_RAM, spi_ram.c and the spi_ram driver name are very generic for a > >>>>> driver that handles one Microchip part. Linux already supports this > >>>>> chip in drivers/mtd/devices/mchp23k256.c (CONFIG_MTD_MCHP23K256), and > >>>>> the binding in dts/upstream/Bindings/mtd/microchip,mchp23k256.yaml > >>>>> lists both microchip,mchp23k256 and microchip,mchp23lcv1024. How about > >>>>> using the Linux names, here and in MAINTAINERS? > >>>>> > >>>> > >>>> I would rather have a generic SPI-RAM driver that also supports MRAM [1] > >>>> and FRAM devices using the common opcode set without erase. > >>>> > >>>> Currently, some FRAM chips are handled by SPI-NOR, but new devices should > >>>> be added to the SPI-RAM driver if it exists. > >>>> > >>>> What are your thoughts on this? > >>> > >>> Seems like a valid argument to me. Simon? What do you think? > >> > >> After looking into patches from Yasir (added to cc). the FRAM > >> case is different. The FRAM (at least the one Yasir adds) has a JEDEC > >> interface, the 23LCV1024 has not! So 23LCV1024 is really special, and I > >> currently tend to say, that Simon is correct, that we should name > >> the 23LCV1024 driver drivers/mtd/devices/mchp23k256.c. > > > > The MRAM (not FRAM) part doesn't support Read ID (JEDEC ID) command. Yasir > > mentions that in the commit description and I checked datasheet [1]. > > Why did you get it has a JEDEC interface? > > Seems I looked into the wrong datasheet! Maybe it is too early for me here... > I need a coffee now. > > Thanks! > > In linux the MRAM Yasir adds, is also handled in spi nor driver. > Yes, it was added quite some time ago. We no longer add new xRAM (non-erase) devices to spi-nor.
> the register 5/1 (read/write status register) and 3/2 (read/write data) > seems the same for both chips and for spi-nor subsystem. > > But, spi-nor and MRAM expect a "status register" and the 23LCV1024 [2] > has there a mode register, with different bit meanings! > I still think we can handle this difference using compatibles and device specific fixup hooks, but... > Seems to me, that is why the 23LCV1024 got his own driver in linux... > even if this is the only obvious difference (not checked deeper now). > > I tend to be in sync with linux here, and still add the MRAM Yasir adds to > the spi-nor driver, and have an own driver for the 23LCV1024 in > drivers/mtd/devices. > keeping in sync with Linux is generally right thing to do😊 > If not I see 2 options: > > a) Yasir adds the MR25H40 to the "spi-ram" driver in this thread > in a follow up series. I tend to say, I first go with driver place > and name Simon proposed. > b) add 23LCV1024 to spi-nor subsystem and find a way to work out mode/status > register differences > > other options? > > b) seems ugly, a) doable... but all options differ to linux approach. > At some point, I plan to propose generic spi-ram driver. I have a few Infineon FRAM devices that would benefit from it. > bye, > Heiko > Anyway, thanks for taking the time to think about this! Takahiro
