starfive-tech/linux.git/drivers/mtd/nand/spi, branch visionfive

mtd: spinand: winbond: Fix oob_layout for W25N01JW

2025-09-05T15:03:44+00:00

Fix the W25N01JW's oob_layout according to the datasheet [1] [1] https://www.winbond.com/hq/product/code-storage-flash-memory/qspinand-flash/?__locale=en&partNo=W25N01JW Fixes: 6a804fb72de5 ("mtd: spinand: winbond: add support for serial NAND flash") Cc: Sridharan S N Cc: stable@vger.kernel.org Signed-off-by: Santhosh Kumar K Signed-off-by: Miquel Raynal

mtd: spinand: winbond: Add comment about the maximum frequency

2025-07-30T09:32:16+00:00

Clarify that Winbond octal capable chips may be clocked at up to 166MHz, which is their absolute maximum. No per-operation maximum value (captured with a "0" in the table) involves that in these cases the maximum frequency of the chip applies, ie. the one commonly described in the DT. Signed-off-by: Miquel Raynal

mtd: spinand: winbond: Enable high-speed modes on w35n0xjw

2025-07-30T09:32:16+00:00

w35n0xjw chips can run at up to 166MHz in octal mode, but this is only possible after programming various VCR registers. Implement the new ->configure_chip() hook for this purpose. Signed-off-by: Miquel Raynal

mtd: spinand: winbond: Enable high-speed modes on w25n0xjw

2025-07-30T09:32:16+00:00

w25n0xjw chips have a high-speed capability hidden in a configuration register. Once enabled, dual/quad SDR reads may be performed at a much higher frequency. Implement the new ->configure_chip() hook for this purpose and configure the SR4 register accordingly. Signed-off-by: Miquel Raynal

mtd: spinand: Add a ->configure_chip() hook

2025-07-30T09:32:16+00:00

There is already a manufacturer hook, which is manufacturer specific but not chip specific. We no longer have access to the actual NAND identity at this stage so let's add a per-chip configuration hook to align the chip configuration (if any) with the core's setting. Signed-off-by: Miquel Raynal

mtd: spinand: Add a frequency field to all READ_FROM_CACHE variants

2025-07-30T09:32:16+00:00

These macros had initially no frequency field. When I added the "maximum operation frequency" field, I did it initially on very common macros and I decided to add an optional field for that (with VA_ARGS) in order to prevent massively unreadable changes. I then added new variants in the spinand.h header, and requested a frequency field for them by default. Some times later, I also added maximum frequencies to other existing variants, but I did it incorrectly, without noticing I was wrong because the field was optional. This mix is error prone, so let's do what I should have done since the very beginning: add a frequency field to all READ_FROM_CACHE variants. There is no functional change. Signed-off-by: Miquel Raynal

spi: spi-mem: Take into account the actual maximum frequency

2025-07-30T09:32:05+00:00

In order to pick the best variant, the duration of each typical operation is derived and then compared. These durations are based on the maximum capabilities of the chips, which are commonly the limiting factors. However there are other possible limiting pieces, such as the hardware layout, EMC considerations and in some cases, the SPI controller itself. We need to take this into account to further refine our variant choice, so let's use the actual frequency that will be used for the operation instead of the theoretical maximum. Signed-off-by: Miquel Raynal Reviewed-by: Mark Brown

mtd: spinand: propagate spinand_wait() errors from spinand_write_page()

2025-07-30T09:27:30+00:00

Since commit 3d1f08b032dc ("mtd: spinand: Use the external ECC engine logic") the spinand_write_page() function ignores the errors returned by spinand_wait(). Change the code to propagate those up to the stack as it was done before the offending change. Cc: stable@vger.kernel.org Fixes: 3d1f08b032dc ("mtd: spinand: Use the external ECC engine logic") Signed-off-by: Gabor Juhos Signed-off-by: Miquel Raynal

mtd: spinand: gigadevice: Add support for GD5F1GM9 chips

2025-07-30T09:27:30+00:00

- GD5F1GM9UExxG (ID:c89101 3.3V) - GD5F1GM9RExxG (ID:c88101 1.8V) Both device feature: - 1Gb density (1024 blocks) - 2048-byte page size with 128-byte OOB - 8-bit ECC requirement per 512 bytes - Quad I/O Read support (opcode EBH) - tPROG ≤ 300us typical page program time Testing environment: - Platform: Raspberry PI-5 (Linux raspberry 6.15.0-rc6-v8) - Operations verified: * Full device read/write/erase cycles on all blocks * Nandspeed: ~ GD5F1GM9UE: 2.75MB/s read, 1.99MB/s write, 41.26MB/s erase ~ GD5F1GM9RE: 1.84MB/s read, 1.45MB/s write, 41.04MS/s erase * Nandbiterrs: Both corredted 8-bit errors per 512 bytes * Stresstest: Both 144k cycles 0 bad block growth Full test log: -U: https://gist.github.com/WT-886/b0f41fb50ddac3adc0020222c1f89b61 -R: https://gist.github.com/WT-886/8784e72f4632d519814928ff49225963 Datasheet: -https://github.com/WT-886/DATASHEET/blob/main/GD5F1GM9-v1.0.pdf Signed-off-by: Teng Wu Signed-off-by: Miquel Raynal

mtd: spinand: fix memory leak of ECC engine conf

2025-06-19T17:13:21+00:00

Memory allocated for the ECC engine conf is not released during spinand cleanup. Below kmemleak trace is seen for this memory leak: unreferenced object 0xffffff80064f00e0 (size 8): comm "swapper/0", pid 1, jiffies 4294937458 hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace (crc 0): kmemleak_alloc+0x30/0x40 __kmalloc_cache_noprof+0x208/0x3c0 spinand_ondie_ecc_init_ctx+0x114/0x200 nand_ecc_init_ctx+0x70/0xa8 nanddev_ecc_engine_init+0xec/0x27c spinand_probe+0xa2c/0x1620 spi_mem_probe+0x130/0x21c spi_probe+0xf0/0x170 really_probe+0x17c/0x6e8 __driver_probe_device+0x17c/0x21c driver_probe_device+0x58/0x180 __device_attach_driver+0x15c/0x1f8 bus_for_each_drv+0xec/0x150 __device_attach+0x188/0x24c device_initial_probe+0x10/0x20 bus_probe_device+0x11c/0x160 Fix the leak by calling nanddev_ecc_engine_cleanup() inside spinand_cleanup(). Signed-off-by: Pablo Martin-Gomez Signed-off-by: Miquel Raynal