[PATCH v3 0/7] mtd: Microchip 23K256 and 23LCV1024 SPI SRAM
Heiko Schocher
hs at nabladev.com
Tue Oct 27 23:11:34 PDT 2026
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
More information about the openwrt-devel
mailing list