The 23LCV1024 is a 1 Mbit serial SRAM with battery backup on an SPI bus, used as non volatile scratch storage. This adds a driver for it and for the 23K256 of the same family, plus a sandbox emulation and unit tests.
The driver sits in UCLASS_MTD, the way the SPI NAND driver does, so the device is reached through the mtd command. v1 put it in UCLASS_SPI_FLASH to borrow the sf command, which meant shimming struct spi_nor fields for a device with no flash semantics. Patch 1 prepares the MTD core for devices which have no erase function. Patch 2 does the same for partitions on such a device, which are aligned on the write size instead of the erase size the device does not have. Without it "mtd list" divides by zero as soon as the device tree gives the RAM partitions. Patch 3 is the driver itself, now in drivers/mtd/devices/mchp23k256.c without erase function, named after the Linux driver and with the 23K256 of the same family alongside the 23LCV1024. Patch 4 is new in v3 and lets the imagemap test pick the SPI-NOR by the partition it needs. It takes the first MTD block device today, which the next patch takes away from it. Found by CI run: https://dev.azure.com/hs0298/hs/_build/results?buildId=223&view=results Patch 5 is the sandbox emulation and the tests. v2 had a patch before it that taught the sandbox SPI bus to bind an emulation from a sandbox,emul phandle. That patch is gone, mainline has the hook since commit 3b748d780a37 ("sandbox: spi: Add SPI EEPROM emulator and DM test"), so the emulation nodes sit at the root of test.dts the way the EEPROM one does. Patch 6 is new in v3 and does for the mtd command what patch 1 does for the MTD core. Read, write and dump get through a device without an erase size, and an erase is refused with a message. Patch 7 is new in v3 as well and moves the transfers of the driver to spi-mem, so that a controller which limits the transfer size or only offers spi-mem operations works. The series was tested on i.MX6 and i.MX8 hardware. This series is now based on the current head of the main branch, dfcfc4c9f78d ("Prepare v2027.01-rc1"). Azure build is clean: https://dev.azure.com/hs0298/hs/_build/results?buildId=224&view=results Changes in v3: - Dropped the sentence saying nobody reads MTD_NO_ERASE, which is wrong, spi-nor sets it for SPI_NOR_NO_ERASE parts. Say instead why the check asks for erasesize and _erase (Simon) - Mention the mtdpart.c hunk, a partition gets part_erase() only when its master has an _erase (Simon) - Added Reviewed-by from Simon, as all comments are in, beside mtd_is_aligned_with_block_size() comment which is moved to patch "cmd: mtd: get through a device that has no erase size" - The two alignment checks no longer rely on MTD_NO_ERASE being set correctly. An alignment of zero counts as 1 with a WARN_ON(), and the partition erase size is only taken when there is one (Simon) - Updated the comment above the first check, which still spoke of the erase size alone (Simon) - Added Reviewed-by from Simon - Named after the Linux driver and moved to drivers/mtd/devices/mchp23k256.c, with CONFIG_MTD_MCHP23K256 and the driver name mchp23k256. drivers/mtd/devices/ is new in U-Boot, it is where the related parts of the family would go (Simon) - Added the microchip,mchp23k256 compatible, 32 KiB with a two byte address, so that the name covers what the driver does. The address width comes from the per compatible data - spi_ram_xfer() dropped, the driver calls spi_write_then_read(), which does the same two transfers (Simon) - The message and the comment in the probe claimed the device powers up in byte operation. The data sheet (DS25156A, section 2.5) gives sequential as the default, and the Linux driver writes the MODE register all the same (Simon) - Removed two comments in probe. The reason for selecting sequential operation is in the commit message, and mtd->_erase is set to NULL explicitly (even if that is redundant), so it is obvious that there is no erase function - did not add Simons comment about the single 128k comment in this patch, instead moved that to a new patch: mtd: mchp23k256: move the transfers to spi-mem - Added Reviewed-by from Simon - New patch. Problem found on CI run: https://dev.azure.com/hs0298/hs/_build/results?buildId=223&view=results The next patch gives the test device tree two MTD devices of its own, one of which took the first mtd_blk away from this test - The patch that taught the sandbox SPI bus to bind an emulation from a sandbox,emul phandle is gone. Mainline has that since commit 3b748d780a37 ("sandbox: spi: Add SPI EEPROM emulator and DM test"), which looks the emulation up with uclass_get_device_by_phandle(). The emulation nodes therefore sit at the root of test.dts, bound by the device tree scan, and the tests no longer unbind anything by hand - The emulation treats whatever follows the address in the first transfer as data, so it follows the data sheet rather than the way the driver splits its transfers. The test sends a write in a single transfer to cover it (Simon) - The erase is asked for over the data that was written, so the check afterwards would see an erase that went through (Simon) - spi_get_bus_and_cs() dropped, the emulation is looked up with the MTD device itself (Simon) - The second partition sits at 0xa001, an offset no erase block boundary allows, and the comment says why that matters. 0xa000 was 8K aligned and proved nothing (Simon) - The emulation powers up in sequential operation, as the data sheet says. The test puts it into byte operation and probes again to see the driver select the mode - Added a test for the 23K256 with its own emulation instance, which is what the second compatible of the driver needs - New patch. Patch 1 only covers mtd_erase(), the mtd command divides by the erase size before it ever gets there. - New patch. Simon pointed out that a single spi_xfer() over the whole array fails where the SPI NAND driver would work Changes in v2: - New patch. The SRAM driver of patch 3 has no erase, which the old mtd_erase() would have turned into a NULL pointer jump - New patch mtd: align a partition on the write size if the device cannot erase Testing on the board dropped for "mtd list" command: ### ERROR ### Please RESET the board ### This is because division by erase_size, which the SPI RAM driver sets to 0. Added for this case also sandbox test. Added comments from Simon: - Moved from UCLASS_SPI_FLASH to UCLASS_MTD, the way the SPI NAND driver sits. The struct spi_nor shim and the dm_spi_flash_ops are gone with it, and the device is reached through the mtd command rather than sf. - Moved from drivers/mtd/spi/ to drivers/mtd/, where the other standalone MTD drivers live. - Dropped the erase operation. v1 filled the range with 0xff from a malloc'd buffer and claimed the bus once per 1 KB chunk. A RAM needs no erase, and patch 1 makes mtd_erase() answer -EOPNOTSUPP. - Dropped the linux/mtd/spi-nor.h include, spi_flash.h pulled it in anyway and it advertised a NOR driver. - sprintf() into a fixed field replaced by snprintf() into a buffer the driver owns. - Copyright: dropped the trailing full stop and added Stefan Bigler's address. fixed checkpatch warning: - Added a MAINTAINERS entry, as the move out of drivers/mtd/spi/ dropped a checkpatch warning. Added comments from Simon: - The test drives the device through the MTD layer instead of the spi_flash uclass. - Uses sandbox_spi_get_emul() rather than reaching into state->spi[][]. - Added a spi1 alias so that dev_seq() of the bus does not depend on probe order. - The erase part checks for -EOPNOTSUPP now. The v1 comment about covering more than one staging step went with the erase loop. - The emulation lives in its own node with its own compatible, which the sandbox SPI bus resolves the phandle to. - Added the emulation and the test to the MAINTAINERS entry. Found while Stefan Bigler tested the series on hardware: - Added partitions to the device in the test device tree and a second test that writes through one of them, which is what "mtd list" on his board fell over. Heiko Schocher (7): mtd: refuse an erase on a device that cannot erase mtd: align a partition on the write size if the device cannot erase mtd: add driver for the Microchip 23K256 and 23LCV1024 SPI SRAM test: boot: imagemap: pick the SPI-NOR by its partition test: dm: add a test for the Microchip 23K256 and 23LCV1024 SPI SRAM cmd: mtd: get through a device that has no erase size mtd: mchp23k256: move the transfers to spi-mem MAINTAINERS | 8 + arch/sandbox/dts/test.dts | 49 ++++ arch/sandbox/include/asm/test.h | 18 ++ cmd/mtd.c | 14 ++ configs/sandbox_defconfig | 2 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/devices/Kconfig | 26 +++ drivers/mtd/devices/Makefile | 4 + drivers/mtd/devices/mchp23k256.c | 220 ++++++++++++++++++ drivers/mtd/devices/mchp23k256_sandbox.c | 268 ++++++++++++++++++++++ drivers/mtd/mtdcore.c | 3 + drivers/mtd/mtdpart.c | 47 +++- drivers/spi/Kconfig | 2 +- test/boot/imagemap.c | 11 +- test/cmd/Makefile | 3 + test/cmd/mtd.c | 79 +++++++ test/dm/Makefile | 1 + test/dm/mchp23k256.c | 272 +++++++++++++++++++++++ 19 files changed, 1015 insertions(+), 15 deletions(-) create mode 100644 drivers/mtd/devices/Kconfig create mode 100644 drivers/mtd/devices/Makefile create mode 100644 drivers/mtd/devices/mchp23k256.c create mode 100644 drivers/mtd/devices/mchp23k256_sandbox.c create mode 100644 test/cmd/mtd.c create mode 100644 test/dm/mchp23k256.c --- base-commit: dfcfc4c9f78d1743f490a497082a4ec8e058aae8 branch: spi-ram-v3 -- 2.55.0
