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? Thanks, Takahiro [1] https://www.mouser.com/datasheet/2/144/EST_MR25H40_prod-2578.pdf?srsltid=AU7gw4XF8HonuNZoC78eWKFbMoaNLlWH1vNgEGA6NH-YFQrIpWVFulpv
