kernel/linux.git/include/linux/mtd/spinand.h, branch v6.6.132

mtd: spinand: Fix kernel doc

2026-03-04T12:20:03+00:00

[ Upstream commit a57b1f07d2d35843a7ada30c8cf9a215c0931868 ] The @data buffer is 5 bytes, not 4, it has been extended for the need of devices with an extra ID bytes. Fixes: 34a956739d29 ("mtd: spinand: Add support for 5-byte IDs") Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin

mtd: spinand: Add support for 5-byte IDs

2024-04-03T13:28:58+00:00

commit 34a956739d295de6010cdaafeed698ccbba87ea4 upstream. E.g. ESMT chips will return an identification code with a length of 5 bytes. In order to prevent ambiguity, flash chips would actually need to return IDs that are up to 17 or more bytes long due to JEDEC's continuation scheme. I understand that if a manufacturer ID is located in bank N of JEDEC's database (there are currently 16 banks), N - 1 continuation codes (7Fh) need to be added to the identification code (comprising of manufacturer ID and device ID). However, most flash chip manufacturers don't seem to implement this (correctly). Signed-off-by: Ezra Buehler Reviewed-by: Martin Kurbanov Tested-by: Martin Kurbanov Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240125200108.24374-2-ezra@easyb.ch Cc: Hauke Mehrtens Signed-off-by: Greg Kroah-Hartman

mtd: spinand: add support for ESMT F50x1G41LB

2023-04-03T16:00:29+00:00

This patch adds support for ESMT F50L1G41LB and F50D1G41LB. It seems that ESMT likes to use random JEDEC ID from other vendors. Their 1G chips uses 0xc8 from GigaDevice and 2G/4G chips uses 0x2c from Micron. For this reason, the ESMT entry is named esmt_c8 with explicit JEDEC ID in variable name. Datasheets: https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50L1G41LB(2M).pdf https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50D1G41LB(2M).pdf Signed-off-by: Chuanhong Guo Signed-off-by: Martin Kurbanov Signed-off-by: Dmitry Rokosov Tested-by: Martin Kurbanov Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20230329114240.378722-1-mmkurbanov@sberdevices.ru

mtd: spinand: Add support for AllianceMemory AS5F34G04SND

2023-01-30T16:16:28+00:00

Add support for AllianceMemory AS5F34G04SND SPI NAND flash Datasheet: - https://www.alliancememory.com/wp-content/uploads/pdf/flash/AllianceMemory_SPI_NAND_Flash_July2020_Rev1.0.pdf Signed-off-by: Mario Kicherer Reviewed-by: Dhruva Gole Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20230126144050.2656358-1-dev@kicherer.org

mtd: spinand: Add support for ATO25D1GA

2022-06-06T13:05:33+00:00

Add support for the ATO25D1GA SPI NAND flash. Datasheet: - https://atta.szlcsc.com/upload/public/pdf/source/20191212/C469320_04599D67B03B078044EB65FF5AEDDDE9.pdf Signed-off-by: Aidan MacDonald Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220604113250.4745-1-aidanmacdonald.0x0@gmail.com

mtd: spinand: Add support for XTX XT26G0xA

2022-04-21T07:34:12+00:00

Add support for XTX Technology XT26G01AXXXXX, XTX26G02AXXXXX and XTX26G04AXXXXX SPI NAND. These are 3V, 1G/2G/4Gbit serial SLC NAND flash devices with on-die ECC (8bit strength per 512bytes). Tested on Teltonika RUTX10 flashed with OpenWrt. Links: - http://www.xtxtech.com/download/?AId=225 - https://datasheet.lcsc.com/szlcsc/2005251034_XTX-XT26G01AWSEGA_C558841.pdf Signed-off-by: Felix Matouschek Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220418132803.664103-1-felix@matouschek.org

mtd: spinand: Create direct mapping descriptors for ECC operations

2022-02-10T08:32:30+00:00

In order for pipelined ECC engines to be able to enable/disable the ECC engine only when needed and avoid races when future parallel-operations will be supported, we need to provide the information about the use of the ECC engine in the direct mapping hooks. As direct mapping configurations are meant to be static, it is best to create two new mappings: one for regular 'raw' accesses and one for accesses involving correction. It is up to the driver to use or not the new ECC enable boolean contained in the spi-mem operation. As dirmaps are not free (they consume a few pages of MMIO address space) and because these extra entries are only meant to be used by pipelined engines, let's limit their use to this specific type of engine and save a bit of memory with all the other setups. Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon Link: https://lore.kernel.org/linux-mtd/20220127091808.1043392-9-miquel.raynal@bootlin.com

mtd: spinand: use the spi-mem poll status APIs

2021-06-03T13:04:57+00:00

Make use of spi-mem poll status APIs to let advanced controllers optimize wait operations. This should also fix the high CPU usage for system that don't have a dedicated STATUS poll block logic. Signed-off-by: Patrice Chotard Signed-off-by: Christophe Kerello Reviewed-by: Boris Brezillon Acked-by: Miquel Raynal Link: https://lore.kernel.org/r/20210518162754.15940-3-patrice.chotard@foss.st.com Signed-off-by: Mark Brown

mtd: spinand: Instantiate a SPI-NAND on-die ECC engine

2020-12-10T21:37:30+00:00

Make use of the existing functions taken from the SPI-NAND core to instantiate an on-die ECC engine specific to the SPI-NAND core. The next step will be to tweak the core to use this object instead of calling the helpers directly. Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200930154109.3922-4-miquel.raynal@bootlin.com

mtd: nand: Rename a core structure

2020-06-26T06:35:04+00:00

Prepare the migration to a generic ECC engine by renaming the nand_ecc_req structure into nand_ecc_props. This structure will be the base of a wider 'nand_ecc' structure. In nand_device, these properties are still named "eccreq" even if "eccprops" might be more descriptive. This is just a transition step, this field is being replaced very soon by a much wider structure. The impact of renaming this field would be huge compared to its interest. Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon Link: https://lore.kernel.org/linux-mtd/20200529002517.3546-14-miquel.raynal@bootlin.com