> Hello Takahiro, > > On 14.10.26 04:54, [email protected] wrote: > > 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. > > Ah! > > For the ones who "share" spi nor interface, we may should extract > that part from spi nor to share the code... but as said, I am not > to deep in the code... > > >> 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... > > It is not only the status register, 23LCV1024 has no WREN (write enable), > nor polll a status register... It is much more simpler... but yes doable. > > > > >> 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😊 > > :-D > > > > >> 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. > > Good to hear... for linux and/or u-boot? > For u-boot. In Linux, FRAM is handled by drivers/nvmem/at25.c as SPI EEPROM compatible devices. If we also want to cover EEPROM in u-boot, then spi-ram may not be the right name...
> so for the series... should I try a more common spi-ram > approach, or go with linux like drivers/mtd/devices/mchp23k256.c ? > So, please go with linux like one. Thanks again, Takahiro
