kernel/include/linux/mtd/spi-nor.h, branch linux-5.2.y

mtd: spi-nor: use 16-bit WRR command when QE is set on spansion flashes

2019-06-23T18:03:34Z

SPI memory devices from different manufacturers have widely different configurations for Status, Control and Configuration registers. JEDEC 216C defines a new map for these common register bits and their functions, and describes how the individual bits may be accessed for a specific device. For the JEDEC 216B compliant flashes, we can partially deduce Status and Configuration registers functions by inspecting the 16th DWORD of BFPT. Older flashes that don't declare the SFDP tables (SPANSION FL512SAIFG1 311QQ063 A ©11 SPANSION) let the software decide how to interact with these registers. The commit dcb4b22eeaf4 ("spi-nor: s25fl512s supports region locking") uncovered a probe error for s25fl512s, when the Quad Enable bit CR[1] was set to one in the bootloader. When this bit is one, only the Write Status (01h) command with two data byts may be used, the 01h command with one data byte is not recognized and hence the error when trying to clear the block protection bits. Fix the above by using the Write Status (01h) command with two data bytes when the Quad Enable bit is one. Backward compatibility should be fine. The newly introduced spi_nor_spansion_clear_sr_bp() is tightly coupled with the spansion_quad_enable() function. Both assume that the Write Register with 16 bits, together with the Read Configuration Register (35h) instructions are supported. Fixes: dcb4b22eeaf44f91 ("spi-nor: s25fl512s supports region locking") Reported-by: Geert Uytterhoeven Signed-off-by: Tudor Ambarus Tested-by: Jonas Bonn Tested-by: Geert Uytterhoeven Reviewed-by: Vignesh Raghavendra Tested-by: Vignesh Raghavendra Signed-off-by: Miquel Raynal

mtd: spi-nor: Fix wrong abbreviation HWCPAS

2019-02-21T07:58:40Z

Change SNOR_HWCPAS_READ_OCTAL to SNOR_HWCAPS_READ_OCTAL. Signed-off-by: Bean Huo Reviewed-by: Tudor Ambarus Signed-off-by: Boris Brezillon

mtd: spi-nor: add opcodes for octal Read/Write commands

2019-01-17T07:43:09Z

- Add opcodes for octal I/O commands * Read : 1-1-8 and 1-8-8 protocol * Write : 1-1-8 and 1-8-8 protocol * opcodes for 4-byte address mode command - Entry of macros in _convert_3to4_xxx function - Add flag SPI_NOR_OCTAL_READ specifying flash support octal read commands. This flag is required for flashes which didn't provides support for auto detection of Octal mode capabilities i.e. not seems to support newer JESD216C standard. Signed-off-by: Vignesh R Signed-off-by: Yogesh Narayan Gaur Reviewed-by: Tudor Ambarus Signed-off-by: Boris Brezillon

mtd: spi-nor: parse SFDP 4-byte Address Instruction Table

2018-12-10T20:59:08Z

Add support for SFDP (JESD216B) 4-byte Address Instruction Table. This table is optional but when available, we parse it to get the 4-byte address op codes supported by the memory. Using these op codes is stateless as opposed to entering the 4-byte address mode or setting the Base Address Register (BAR). Flashes that have the 4BAIT table declared can now support SPINOR_OP_PP_1_1_4_4B and SPINOR_OP_PP_1_4_4_4B opcodes. Tested on MX25L25673G. Signed-off-by: Cyrille Pitchen [tudor.ambarus@microchip.com: - rework erase and page program logic, - pass DMA-able buffer to spi_nor_read_sfdp(), - introduce SPI_NOR_HAS_4BAIT - various minor updates.] Signed-off-by: Tudor Ambarus Signed-off-by: Boris Brezillon

mtd: spi-nor: Add an SPDX tag to spi-nor.{c,h}

2018-12-10T20:59:08Z

Add SPDX tags to replace the license boiler-plate and fix the MODULE_LICENSE() definition in spi-nor.c to match the license text (GPL v2). Interestingly, spi-nor.h and spi-nor.c do not use the same license (GPL v2+ for spi-nor.h, GPL v2 for spi-nor.c). Signed-off-by: Boris Brezillon Reviewed-by: Tudor Ambarus

mtd: spi-nor: Add the SNOR_F_4B_OPCODES flag

2018-12-10T20:59:07Z

Some flash_info entries have the SPI_NOR_4B_OPCODES flag set to let the core know that the flash supports 4B opcode. While this solution works fine for id-based caps detection, it doesn't work that well when relying on SFDP-based caps detection. Let's add an SNOR_F_4B_OPCODES flag so that the SFDP parsing code can set it when appropriate. Signed-off-by: Boris Brezillon Reviewed-by: Tudor Ambarus

mtd: spi-nor: add macros related to MICRON flash

2018-12-10T20:59:07Z

Some MICRON related macros in spi-nor domain were ST. Rename entries related to STMicroelectronics under macro SNOR_MFR_ST. Added entry of MFR Id for Micron flashes, 0x002C. Signed-off-by: Yogesh Gaur Reviewed-by: Tudor Ambarus Signed-off-by: Boris Brezillon

mtd: spi-nor: parse SFDP Sector Map Parameter Table

2018-10-08T19:28:26Z

Add support for the SFDP (JESD216B) Sector Map Parameter Table. This table is optional, but when available, we parse it to identify the location and size of sectors within the main data array of the flash memory device and to identify which Erase Types are supported by each sector. Signed-off-by: Tudor Ambarus Reviewed-by: Marek Vasut Signed-off-by: Boris Brezillon

mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories

2018-10-08T19:28:26Z

Based on Cyrille Pitchen's patch https://lkml.org/lkml/2017/3/22/935. This patch is a transitional patch in introducing the support of SFDP SPI memories with non-uniform erase sizes like Spansion s25fs512s. Non-uniform erase maps will be used later when initialized based on the SFDP data. Introduce the memory erase map which splits the memory array into one or many erase regions. Each erase region supports up to 4 erase types, as defined by the JEDEC JESD216B (SFDP) specification. To be backward compatible, the erase map of uniform SPI NOR flash memories is initialized so it contains only one erase region and this erase region supports only one erase command. Hence a single size is used to erase any sector/block of the memory. Besides, since the algorithm used to erase sectors on non-uniform SPI NOR flash memories is quite expensive, when possible, the erase map is tuned to come back to the uniform case. The 'erase with the best command, move forward and repeat' approach was suggested by Cristian Birsan in a brainstorm session, so: Suggested-by: Cristian Birsan Signed-off-by: Tudor Ambarus Reviewed-by: Marek Vasut Signed-off-by: Boris Brezillon

mtd: spi-nor: only apply reset hacks to broken hardware

2018-08-01T07:27:38Z

Commit 59b356ffd0b0 ("mtd: m25p80: restore the status of SPI flash when exiting") is the latest from a long history of attempts to add reboot handling to handle stateful addressing modes on SPI flash. Some prior mostly-related discussions: http://lists.infradead.org/pipermail/linux-mtd/2013-March/046343.html [PATCH 1/3] mtd: m25p80: utilize dedicated 4-byte addressing commands http://lists.infradead.org/pipermail/barebox/2014-September/020682.html [RFC] MTD m25p80 3-byte addressing and boot problem http://lists.infradead.org/pipermail/linux-mtd/2015-February/057683.html [PATCH 2/2] m25p80: if supported put chip to deep power down if not used Previously, attempts to add reboot-time software reset handling were rejected, but the latest attempt was not. Quick summary of the problem: Some systems (e.g., boot ROM or bootloader) assume that they can read initial boot code from their SPI flash using 3-byte addressing. If the flash is left in 4-byte mode after reset, these systems won't boot. The above patch provided a shutdown/remove hook to attempt to reset the addressing mode before we reboot. Notably, this patch misses out on huge classes of unexpected reboots (e.g., crashes, watchdog resets). Unfortunately, it is essentially impossible to solve this problem 100%: if your system doesn't know how to reset the SPI flash to power-on defaults at initialization time, no amount of software can really rescue you -- there will always be a chance of some unexpected reset that leaves your flash in an addressing mode that your boot sequence didn't expect. While it is not directly harmful to perform hacks like the aforementioned commit on all 4-byte addressing flash, a properly-designed system should not need the hack -- and in fact, providing this hack may mask the fact that a given system is indeed broken. So this patch attempts to apply this unsound hack more narrowly, providing a strong suggestion to developers and system designers that this is truly a hack. With luck, system designers can catch their errors early on in their development cycle, rather than applying this hack long term. But apparently enough systems are out in the wild that we still have to provide this hack. Document a new device tree property to denote systems that do not have a proper hardware (or software) reset mechanism, and apply the hack (with a loud warning) only in this case. Signed-off-by: Brian Norris Reviewed-by: Guenter Roeck Signed-off-by: Boris Brezillon