summaryrefslogtreecommitdiff
path: root/drivers/mtd/spi-nor
AgeCommit message (Collapse)AuthorFilesLines
2021-02-05mtd: spi-nor: sst: Add support for Global Unlock on sst26vfTudor Ambarus3-3/+52
Even if sst26vf shares the SPINOR_OP_GBULK opcode with Macronix (ex. MX25U12835F) and Winbound (ex. W25Q128FV), it has its own Individual Block Protection scheme, which is also capable to read-lock individual parameter blocks. Thus the sst26vf's Individual Block Protection scheme will reside in the sst.c manufacturer driver. Add support to unlock the entire flash memory. The device is write-protected by default after a power-on reset cycle (volatile software protection), in order to avoid inadvertent writes during power-up. Could do an erase, write, read back, and compare when MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE=y. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210121110546.382633-2-tudor.ambarus@microchip.com
2021-02-05mtd: spi-nor: Add Global Block Unlock commandTudor Ambarus2-0/+38
The Global Block Unlock command has different names depending on the manufacturer, but always the same command value: 0x98. Macronix's MX25U12835F names it Gang Block Unlock, Winbond's W25Q128FV names it Global Block Unlock and Microchip's SST26VF064B names it Global Block Protection Unlock. Used in the Individual Block Protection mode, which is mutually exclusive with the Block Protection mode (BP0-3). Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210121110546.382633-1-tudor.ambarus@microchip.com
2021-02-05mtd: spi-nor: core: Add erase size check for erase command initializationTakahiro Kuwano1-0/+1
Even if erase type is same as previous region, erase size can be different if the previous region is overlaid region. Since 'region->size' is assigned to 'cmd->size' for overlaid region, comparing 'erase->size' and 'cmd->size' can detect previous overlaid region. Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> [ta: Add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/13d47e8d8991b8a7fd8cc7b9e2a5319c56df35cc.1601612872.git.Takahiro.Kuwano@infineon.com
2021-02-05mtd: spi-nor: core: Fix erase type discovery for overlaid regionTakahiro Kuwano1-4/+5
In case of overlaid regions in which their biggest erase size command overpasses in size the region's size, only the non-overlaid portion of the sector gets erased. For example, if a Sector Erase command is applied to a 256-kB range that is overlaid by 4-kB sectors, the overlaid 4-kB sectors are not affected by the erase. For overlaid regions, 'region->size' is assigned to 'cmd->size' later in spi_nor_init_erase_cmd(), so 'erase->size' can be greater than 'len'. Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> [ta: Update commit description, add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/fa5d8b944a5cca488ac54ba37c95e775ac2deb34.1601612872.git.Takahiro.Kuwano@infineon.com
2021-02-05mtd: spi-nor: sfdp: Fix last erase region markingTakahiro Kuwano1-2/+1
The place of spi_nor_region_mark_end() must be moved, because 'i' is re-used for the index of erase[]. Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> [ta: Add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/02ce8d84b7989ebee33382f6494df53778dd508e.1601612872.git.Takahiro.Kuwano@infineon.com
2021-02-05mtd: spi-nor: sfdp: Fix wrong erase type bitmask for overlaid regionTakahiro Kuwano1-1/+1
At the time spi_nor_region_check_overlay() is called, the erase types are sorted in ascending order of erase size. The 'erase_type' should be masked with 'BIT(erase[i].idx)' instead of 'BIT(i)'. Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> [ta: Add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/fd90c40d5b626a1319a78fc2bcee79a8871d4d57.1601612872.git.Takahiro.Kuwano@infineon.com
2021-01-23mtd: spi-nor: hisi-sfc: Put child node np on error pathPan Bian1-1/+3
Put the child node np when it fails to get or register device. Fixes: e523f11141bd ("mtd: spi-nor: add hisilicon spi-nor flash controller driver") Cc: stable@vger.kernel.org Signed-off-by: Pan Bian <bianpan2016@163.com> [ta: Add Fixes tag and Cc stable] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20210121091847.85362-1-bianpan2016@163.com
2021-01-23mtd: spi-nor: intel-spi: Add support for Intel Alder Lake-P SPI serial flashMika Westerberg1-0/+1
Intel Alder Lake-P has the same SPI serial flash controller as Alder Lake-S. Add Alder Lake-P PCI ID to the driver list of supported devices. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20210113101545.71579-1-mika.westerberg@linux.intel.com
2020-12-16Merge tags 'spi-nor/for-5.11' and 'nand/for-5.11' into mtd/nextMiquel Raynal11-199/+1202
SPI NOR core changes: - Initial support for stateful Octal DTR mode using volatile settings - Preliminary support for JEDEC 251 (xSPI) and JEDEC 216D standards - Support for Cypress Semper flash - Support to specify ECC block size of SPI NOR flashes - Fixes to avoid clearing of non-volatile Block Protection bits at probe Generic NAND core: * ECC management: - Add an I/O request tweaking mechanism - Entire rework of the software BCH ECC driver, creation of a real ECC engine, getting rid of raw NAND structures, migration to more generic prototypes, misc fixes and style cleanup. Moved now to the Generic NAND layer. - Entire rework of the software Hamming ECC driver, creation of a real ECC engine, getting rid of raw NAND structures, misc renames, comment updates, cleanup, and style fixes. Moved now to the generic NAND layer. - Necessary plumbing at the NAND level to retrieve generic NAND ECC engines (softwares and on-die). - Update of the bindings. Raw NAND core: * Geting rid of the chip->ecc.priv entry. * Fix miscellaneous typos in kernel-doc Raw NAND controller drivers: * AU1550: Ensure the presence of the right includes * Davinci: Do not use extra dereferencing * GPMI: - Fix the driver only sense CS0 R/B issue - Fix the random DMA timeout issue - Use a single line for of_device_id - Use of_device_get_match_data() - Fix reference count leak in gpmi ops - Cleanup makefile - Fix binding matching of clocks on different SoCs * Ingenic: remove redundant get_device() in ingenic_ecc_get() * Intel LGM: New NAND controller driver * Marvell: Drop useless line * Meson: - Fix a resource leak in init - Fix meson_nfc_dma_buffer_release() arguments * mxc: - Use device_get_match_data() - Use a single line for of_device_id - Remove platform data support * Qcom: - Add support for SDX55 - Support for IPQ6018 QPIC NAND controller - Fix DMA sync on FLASH_STATUS register read * Rockchip: New NAND controller driver for RK3308, RK2928 and others * Sunxi: Add MDMA support SPI-NAND core: * Creation of a SPI-NAND on-die ECC engine * Move ECC related definitions earlier in the driver * Fix typo in comment * Fill a default ECC provider/algorithm * Remove outdated comment * Fix OOB read * Allow the case where there is no ECC engine * Use the external ECC engine logic SPI-NAND chip drivers: * Micron: - Add support for MT29F2G01AAAED - Use more specific names * Macronix: - Add support for MX35LFxG24AD - Add support for MX35LFxGE4AD Others: * onenand: Use mtd->oops_panic_write as condition * plat-ram: correctly free memory on error path in platram_probe()
2020-12-07mtd: spi-nor: keep lock bits if they are non-volatileMichael Walle7-24/+211
Traditionally, Linux unlocks the whole flash because there are legacy devices which has the write protection bits set by default at startup. If you actually want to use the flash protection bits, eg. because there is a read-only part for a bootloader, this automatic unlocking is harmful. If there is no hardware write protection in place (usually called WP#), a startup of the kernel just discards this protection. I've gone through the datasheets of all the flashes (except the Intel ones where I could not find any datasheet nor reference) which supports the unlocking feature and looked how the sector protection was implemented. The currently supported flashes can be divided into the following two categories: (1) block protection bits are non-volatile. Thus they keep their values at reset and power-cycle (2) flashes where these bits are volatile. After reset or power-cycle, the whole memory array is protected. (a) some devices needs a special "Global Unprotect" command, eg. the Atmel AT25DF041A. (b) some devices require to clear the BPn bits in the status register. Due to the reasons above, we do not want to clear the bits for flashes which belong to category (1). Fortunately for us, only Atmel flashes fall into category (2a). Implement the "Global Protect" and "Global Unprotect" commands for these. For (2b) we can use normal block protection locking scheme. This patch adds a new flag to indicate the case (2). Only if we have such a flash we unlock the whole flash array. To be backwards compatible it also introduces a kernel configuration option which restores the complete legacy behavior ("Disable write protection on any flashes"). Hopefully, this will clean up "unlock the entire flash for legacy devices" once and for all. For reference here are the actually commits which introduced the legacy behavior (and extended the behavior to other chip manufacturers): commit f80e521c916cb ("mtd: m25p80: add support for the Intel/Numonyx {16,32,64}0S33B SPI flash chips") commit ea60658a08f8f ("mtd: m25p80: disable SST software protection bits by default") commit 7228982442365 ("[MTD] m25p80: fix bug - ATmel spi flash fails to be copied to") Actually, this might also fix handling of the Atmel AT25DF flashes, because the original commit 7228982442365 ("[MTD] m25p80: fix bug - ATmel spi flash fails to be copied to") was writing a 0 to the status register, which is a "Global Unprotect". This might not be the case in the current code which only handles the block protection bits BP2, BP1 and BP0. Thus, it depends on the current contents of the status register if this unlock actually corresponds to a "Global Unprotect" command. In the worst case, the current code might leave the AT25DF flashes in a write protected state. The commit 191f5c2ed4b6f ("mtd: spi-nor: use 16-bit WRR command when QE is set on spansion flashes") changed that behavior by just clearing BP2 to BP0 instead of writing a 0 to the status register. Further, the commit 3e0930f109e76 ("mtd: spi-nor: Rework the disabling of block write protection") expanded the unlock_all() feature to ANY flash which supports locking. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-8-michael@walle.cc
2020-12-07mtd: spi-nor: atmel: fix unlock_all() for AT25FS010/040Michael Walle3-3/+53
These flashes have some weird BP bits mapping which aren't supported in the current locking code. Just add a simple unlock op to unprotect the entire flash array which is needed for legacy behavior. Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write protection") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-7-michael@walle.cc
2020-12-07mtd: spi-nor: intel: remove global protection flagMichael Walle1-13/+3
For the Atmel and SST parts this flag was already moved to individual flash parts because it is considered bad esp. because newer flash chips will automatically inherit the "has locking" support. While this won't likely be the case for the Intel parts, we do it for consistency reasons. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-6-michael@walle.cc
2020-12-07mtd: spi-nor: sst: remove global protection flagMichael Walle1-18/+12
This is considered bad for the following reasons: (1) We only support the block protection with BPn bits for write protection. Not all SST parts support this. (2) Newly added flash chip will automatically inherit the "has locking" support and thus needs to explicitly tested. Better be opt-in instead of opt-out. (3) There are already supported flashes which doesn't support the locking scheme. So I assume this wasn't properly tested before adding that chip; which enforces my previous argument that locking support should be an opt-in. Remove the global flag and add individual flags to all flashes which supports BP locking. In particular the following flashes don't support the BP scheme: - SST26VF016B - SST26WF016B - SST26VF064B Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-5-michael@walle.cc
2020-12-07mtd: spi-nor: atmel: remove global protection flagMichael Walle1-19/+9
This is considered bad for the following reasons: (1) We only support the block protection with BPn bits for write protection. Not all Atmel parts support this. (2) Newly added flash chip will automatically inherit the "has locking" support and thus needs to explicitly tested. Better be opt-in instead of opt-out. (3) There are already supported flashes which doesn't support the locking scheme. So I assume this wasn't properly tested before adding that chip; which enforces my previous argument that locking support should be an opt-in. Remove the global flag and add individual flags to all flashes which supports BP locking. In particular the following flashes don't support the BP scheme: - AT26F004 - AT25SL321 - AT45DB081D Please note, that some flashes which are marked as SPI_NOR_HAS_LOCK just support Global Protection, i.e. not our supported block protection locking scheme. This is to keep backwards compatibility with the current "unlock all at boot" mechanism. In particular the following flashes doesn't have BP bits: - AT25DF041A - AT25DF321 - AT25DF321A - AT25DF641 - AT26DF081A - AT26DF161A - AT26DF321 Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-4-michael@walle.cc
2020-12-07mtd: spi-nor: ignore errors in spi_nor_unlock_all()Michael Walle1-10/+13
Just try to unlock the whole SPI-NOR flash array. Don't abort the probing in case of an error. Justifications: (1) For some boards, this just works because spi_nor_write_16bit_sr_and_check() is broken and just checks the second half of the 16bit. Once that will be fixed, SPI probe will fail for boards which has hardware-write protected SPI-NOR flashes. (2) Until now, hardware write-protection was the only viable solution to use the block protection bits. This is because this very function spi_nor_unlock_all() will be called unconditionally on every linux boot. Therefore, this bits only makes sense in combination with the hardware write-protection. If we would fail the SPI probe on an error in spi_nor_unlock_all() we'd break virtually all users of the block protection bits. (3) We should try hard to keep the MTD working even if the flash might not be writable/erasable. Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write protection") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-3-michael@walle.cc
2020-12-07mtd: spi-nor: sst: fix BPn bits for the SST25VF064CMichael Walle1-1/+2
This flash part actually has 4 block protection bits. Please note, that this patch is just based on information of the datasheet of the datasheet and wasn't tested. Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write protection") Reported-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-2-michael@walle.cc
2020-12-07mtd: spi-nor: spansion: Set ECC block sizePratyush Yadav1-0/+1
The S28 flash family uses 2-bit ECC by default with each ECC block being 16 bytes. Under this scheme multi-pass programming to an ECC block is not allowed. Set the writesize to make sure multi-pass programming is not attempted on the flash. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201201102711.8727-4-p.yadav@ti.com
2020-12-07mtd: spi-nor: core: Allow flashes to specify MTD writesizePratyush Yadav2-1/+5
Some flashes like the Cypress S28 family use ECC. Under this ECC scheme, multi-pass writes to an ECC block is not allowed. In other words, once data is programmed to an ECC block, it can't be programmed again without erasing it first. Upper layers like file systems need to be given this information so they do not cause error conditions on the flash by attempting multi-pass programming. This can be done by setting 'writesize' in 'struct mtd_info'. Set the default to 1 but allow flashes to modify it in fixup hooks. If more flashes show up with this constraint in the future it might be worth it to add it to 'struct flash_info', but for now increasing its size is not worth it. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201201102711.8727-3-p.yadav@ti.com
2020-12-07mtd: spi-nor: Fix multiple typosJonathan Neuschäfer2-3/+3
There are a few typos in comments in the SPI NOR framework; fix them. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201130152416.1283972-1-j.neuschaefer@gmx.net
2020-11-20mtd: spi-nor: hisi-sfc: Demote non-conformant kernel-docLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter or member 'np' not described in 'hisi_spi_nor_register' drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter or member 'host' not described in 'hisi_spi_nor_register' Cc: Tudor Ambarus <tudor.ambarus@microchip.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-mtd@lists.infradead.org Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-8-lee.jones@linaro.org
2020-11-09mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR modePratyush Yadav1-1/+114
Since this flash doesn't have a Profile 1.0 table, the Octal DTR capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D fast read settings. Enable Octal DTR mode with 20 dummy cycles to allow running at the maximum supported frequency of 200Mhz. The flash supports the soft reset sequence. So, add the flag in the flash's info. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-16-p.yadav@ti.com
2020-11-09mtd: spi-nor: spansion: add support for Cypress Semper flashPratyush Yadav1-0/+171
The Cypress Semper flash is an xSPI compliant octal DTR flash. Add support for using it in octal DTR mode. The flash by default boots in a hybrid sector mode. But the sector map table on the part I had was programmed incorrectly and the SMPT values on the flash don't match the public datasheet. Specifically, in some places erase type 3 was used instead of 4. In addition, the region sizes were incorrect in some places. So, for testing I set CFR3N[3] to enable uniform sector sizes. Since the uniform sector mode bit is a non-volatile bit, this series does not change it to avoid making any permanent changes to the flash configuration. The correct data to implement a fixup is not available right now and will be done in a follow-up patch if needed. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> [vigneshr@ti.com: Drop unnecessary sleep in Octal DTR switch sequence] Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-15-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: disable Octal DTR mode on suspend.Pratyush Yadav1-0/+15
On resume, the init procedure will be run that will re-enable it. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-14-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: perform a Soft Reset on shutdownPratyush Yadav1-0/+45
Perform a Soft Reset on shutdown on flashes that support it so that the flash can be reset to its initial state and any configurations made by spi-nor (given that they're only done in volatile registers) will be reset. This will hand back the flash in pristine state for any further operations on it. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-13-p.yadav@ti.com
2020-11-09mtd: spi-nor: sfdp: detect Soft Reset sequence support from BFPTPratyush Yadav3-0/+7
A Soft Reset sequence will return the flash to Power-on-Reset (POR) state. It consists of two commands: Soft Reset Enable and Soft Reset. Find out if the sequence is supported from BFPT DWORD 16. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-12-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: enable octal DTR mode when possiblePratyush Yadav2-0/+40
Allow flashes to specify a hook to enable octal DTR mode. Use this hook whenever possible to get optimal transfer speeds. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-11-p.yadav@ti.com
2020-11-09mtd: spi-nor: Parse SFDP SCCR MapTudor Ambarus1-0/+48
Parse just the 22nd dword and look for the 'DTR Octal Mode Enable Volatile bit'. SPI_NOR_IO_MODE_EN_VOLATILE should be set just for the flashes that don't define the optional SFDP SCCR Map. For the others, let the SFDP do its job and fill the SNOR_F_IO_MODE_EN_VOLATILE flag. We avoid this way polluting the flash flags when declaring one. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20201005153138.6437-10-p.yadav@ti.com
2020-11-09mtd: spi-nor: Introduce SNOR_F_IO_MODE_EN_VOLATILETudor Ambarus2-0/+9
We don't want to enter a stateful mode, where a X-X-X I/O mode is entered by setting a non-volatile bit, because in case of a reset or a crash, once in the non-volatile mode, we may not be able to recover in bootloaders and we may break the SPI NOR boot. Forbid by default the I/O modes that are set via a non-volatile bit. SPI_NOR_IO_MODE_EN_VOLATILE should be set just for the flashes that don't define the optional SFDP SCCR Map, so that we don't pollute the flash info flags. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20201005153138.6437-9-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR modePratyush Yadav1-2/+13
Some controllers, like the cadence qspi controller, have trouble reading only 1 byte in DTR mode. So, do 2 byte reads for SR and FSR commands in DTR mode, and then discard the second byte. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-8-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: use dummy cycle and address width info from SFDPPratyush Yadav1-0/+10
The xSPI Profile 1.0 table specifies how many dummy cycles and address bytes are needed for the Read Status Register command in octal DTR mode. Use that information to send the correct Read SR command. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-7-p.yadav@ti.com
2020-11-09mtd: spi-nor: sfdp: parse xSPI Profile 1.0 tablePratyush Yadav3-1/+102
This table is indication that the flash is xSPI compliant and hence supports octal DTR mode. Extract information like the fast read opcode, dummy cycles, the number of dummy cycles needed for a Read Status Register command, and the number of address bytes needed for a Read Status Register command. We don't know what speed the controller is running at. Find the fast read dummy cycles for the fastest frequency the flash can run at to be sure we are never short of dummy cycles. If nothing is available, default to 20. Flashes that use a different value should update it in their fixup hooks. Since we want to set read settings, expose spi_nor_set_read_settings() in core.h. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-6-p.yadav@ti.com
2020-11-09mtd: spi-nor: sfdp: get command opcode extension type from BFPTPratyush Yadav2-0/+24
Some devices in DTR mode expect an extra command byte called the extension. The extension can either be same as the opcode, bitwise inverse of the opcode, or another additional byte forming a 16-byte opcode. Get the extension type from the BFPT. For now, only flashes with "repeat" and "inverse" extensions are supported. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-5-p.yadav@ti.com
2020-11-09mtd: spi-nor: add support for DTR protocolPratyush Yadav3-83/+252
Double Transfer Rate (DTR) is SPI protocol in which data is transferred on each clock edge as opposed to on each clock cycle. Make framework-level changes to allow supporting flashes in DTR mode. Right now, mixed DTR modes are not supported. So, for example a mode like 4S-4D-4D will not work. All phases need to be either DTR or STR. The xSPI spec says that "The program commands provide SPI backward compatible commands for programming data...". So 8D-8D-8D page program opcodes are populated with using 1S-1S-1S opcodes. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-4-p.yadav@ti.com
2020-11-09mtd: spi-nor: add spi_nor_controller_ops_{read_reg, write_reg, erase}()Pratyush Yadav1-34/+53
They are thin wrappers around nor->controller_ops->{read_reg,write_reg,erase}(). In a future commit DTR support will be added. These ops can not be supported by the controller_ops hooks and these helpers will make it easier to reject those calls. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-3-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: use EOPNOTSUPP instead of ENOTSUPPPratyush Yadav1-5/+5
ENOTSUPP is not a SUSV4 error code. Using EOPNOTSUPP is preferred in its stead. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-2-p.yadav@ti.com
2020-10-28mtd: spi-nor: Fix address width on flash chips > 16MBBert Vermeulen1-3/+5
If a flash chip has more than 16MB capacity but its BFPT reports BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, the spi-nor framework defaults to 3. The check in spi_nor_set_addr_width() doesn't catch it because addr_width did get set. This fixes that check. Fixes: f9acd7fa80be ("mtd: spi-nor: sfdp: default to addr_width of 3 for configurable widths") Signed-off-by: Bert Vermeulen <bert@biot.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Joel Stanley <joel@jms.id.au> Tested-by: Cédric Le Goater <clg@kaod.org> Link: https://lore.kernel.org/r/20201006132346.12652-1-bert@biot.com
2020-10-28mtd: spi-nor: Don't copy self-pointing struct aroundAlexander Sverdlin1-3/+2
spi_nor_parse_sfdp() modifies the passed structure so that it points to itself (params.erase_map.regions to params.erase_map.uniform_region). This makes it impossible to copy the local struct anywhere else. Therefore only use memcpy() in backup-restore scenario. The bug may show up like below: BUG: unable to handle page fault for address: ffffc90000b377f8 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 3500 Comm: flashcp Tainted: G O 5.4.53-... #1 ... RIP: 0010:spi_nor_erase+0x8e/0x5c0 Code: 64 24 18 89 db 4d 8b b5 d0 04 00 00 4c 89 64 24 18 4c 89 64 24 20 eb 12 a8 10 0f 85 59 02 00 00 49 83 c6 10 0f 84 4f 02 00 00 <49> 8b 06 48 89 c2 48 83 e2 c0 48 89 d1 49 03 4e 08 48 39 cb 73 d8 RSP: 0018:ffffc9000217fc48 EFLAGS: 00010206 RAX: 0000000000740000 RBX: 0000000000000000 RCX: 0000000000740000 RDX: ffff8884550c9980 RSI: ffff88844f9c0bc0 RDI: ffff88844ede7bb8 RBP: 0000000000740000 R08: ffffffff815bfbe0 R09: ffff88844f9c0bc0 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000217fc60 R13: ffff88844ede7818 R14: ffffc90000b377f8 R15: 0000000000000000 FS: 00007f4699780500(0000) GS:ffff88846ff00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90000b377f8 CR3: 00000004538ee000 CR4: 0000000000340fe0 Call Trace: part_erase+0x27/0x50 mtdchar_ioctl+0x831/0xba0 ? filemap_map_pages+0x186/0x3d0 ? do_filp_open+0xad/0x110 ? _copy_to_user+0x22/0x30 ? cp_new_stat+0x150/0x180 mtdchar_unlocked_ioctl+0x2a/0x40 do_vfs_ioctl+0xa0/0x630 ? __do_sys_newfstat+0x3c/0x60 ksys_ioctl+0x70/0x80 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x6a/0x200 ? prepare_exit_to_usermode+0x50/0xd0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f46996b6817 Cc: stable@vger.kernel.org Fixes: c46872170a54 ("mtd: spi-nor: Move erase_map to 'struct spi_nor_flash_parameter'") Co-developed-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com> Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Tested-by: Baurzhan Ismagulov <ibr@radix50.net> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005084803.23460-1-alexander.sverdlin@nokia.com
2020-10-06Revert "mtd: spi-nor: Prefer asynchronous probe"Vignesh Raghavendra1-1/+0
This reverts commit 03edda0e1edaa3c2e99239c66e3c14d749318fd6. This leads to warn dump like [1] on some platforms and reorders MTD devices which may break user space expectations [2]. So revert the change. [1]: [ 1.849801] ------------[ cut here ]------------ [ 1.854271] mscc_felix 0000:00:00.5: device is disabled, skipping [ 1.858753] WARNING: CPU: 1 PID: 7 at kernel/kmod.c:136 __request_module+0x3a4/0x568 [...] [2] Bug report: https://lore.kernel.org/linux-mtd/20201003150633.23416-1-michael@walle.cc/ Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20201005090321.8724-1-vigneshr@ti.com
2020-09-29mtd: spi-nor: winbond: Add support for w25q64jwmIkjoon Jang1-0/+9
Add support Winbond w25q{64,128,256}jwm which are identical to existing w25q32jwm except for their sizes. This was tested with w25q64jwm, basic erase/write/readback and lock/unlock both lower/upper blocks were okay. Signed-off-by: ikjn@chromium.org <ikjn@chromium.org> Signed-off-by: Xingyu Wu <wuxy@bitland.corp-partner.google.com> Signed-off-by: ST Lin <stlin2@winbond.com> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20200928060631.2090541-1-ikjn@chromium.org
2020-09-29mtd: spi-nor: intel-spi: Add support for Intel Alder Lake-S SPI serial flashMika Westerberg1-0/+1
Intel Alder Lake-S has the same SPI serial flash controller as Cannon Lake. Add Alder Lake-S PCI ID to the driver list of supported devices. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20200925095109.51148-1-mika.westerberg@linux.intel.com
2020-09-29mtd: spi-nor: macronix: Add SECT_4K to mx25l12805dRobert Marko1-1/+1
According to the mx25l12805d datasheet it supports using 4K or 64K sectors. So lets add the SECT_4K to enable 4K sector usage. Datasheet: https://www.mxic.com.tw/Lists/Datasheet/Attachments/7321/MX25L12805D,%203V,%20128Mb,%20v1.2.pdf Cc: Luka Perkov <luka.perkov@sartura.hr> Signed-off-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20200915100623.708736-1-robert.marko@sartura.hr
2020-09-29mtd: spi-nor: Prefer asynchronous probeDouglas Anderson1-0/+1
On my system the spi_nor_probe() took ~6 ms at bootup. That's not a lot, but every little bit adds up to a slow bootup. While we can get this out of the boot path by making it a module, there are times where it is convenient (or even required) for this to be builtin the kernel. Let's set that we prefer async probe so that we don't block other drivers from probing while we are probing. This is a tiny little change that is almost guaranteed to be safe for anything that is able to run as a module, which SPI_NOR is. Specifically modules are already probed asynchronously. Also: since other things in the system may have enabled asynchronous probe the system may already be doing other things during our probe. There is a small possibility that some other driver that was a client of SPI_NOR didn't handle -EPROBE_DEFER and was relying on probe ordering and only worked when the SPI_NOR and the SPI bus were builtin. In that case the other driver has a bug that's waiting to hit and the other driver should be fixed. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20200902160002.1.I658d1c0db9adfeb9a59bc55e96a19e192c959e55@changeid
2020-09-14Revert "mtd: spi-nor: Add capability to disable flash quad mode"Yicong Yang2-41/+24
As the only user has been removed in previous patch, let's revert this one together. This reverts commit be192209d5a33c912caa4a05d6f92b89328d8db8. Reported-by: Matthias Weisser <m.weisser.m@gmail.com> Suggested-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/1599205640-26690-2-git-send-email-yangyicong@hisilicon.com
2020-09-14Revert "mtd: spi-nor: Disable the flash quad mode in spi_nor_restore()"Yicong Yang1-2/+0
Previous patch intends to restore the flash's QE bit when removed/shutdown, but may have some problems and break the flash: - for those originally in Quad mode, this patch will clear the QE bit when unloaded the flash, which is incorrect. - even with above problem solved, it may still break the flash as some flash's QE bit is non-volatile and lots of set/reset will wear out the bit. - the restore method cannot be proved to be valid as if a hard reset or accident crash happened, the spi_nor_restore() won't be performed the the QE bit will not be restored as we expected to. So let's revert it to fix this. The discussion can be found at [1]. This reverts commit cc59e6bb6cd69d3347c06ccce088c5c6052e041e. [1] https://lore.kernel.org/linux-mtd/CAO8h3eFLVLRmw7u+rurKsg7=Nh2q-HVq-HgVXig8gf5Dffk8MA@mail.gmail.com/ Reported-by: Matthias Weisser <m.weisser.m@gmail.com> Suggested-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/1599205640-26690-1-git-send-email-yangyicong@hisilicon.com
2020-07-28mtd: revert "spi-nor: intel: provide a range for poll_timout"Luis Alberto Herrera1-2/+2
This change reverts aba3a882a178: "mtd: spi-nor: intel: provide a range for poll_timout". That change introduces a performance regression when reading sequentially from flash. Logging calls to intel_spi_read without this change we get: Start MTD read [ 20.045527] intel_spi_read(from=1800000, len=400000) [ 20.045527] intel_spi_read(from=1800000, len=400000) [ 282.199274] intel_spi_read(from=1c00000, len=400000) [ 282.199274] intel_spi_read(from=1c00000, len=400000) [ 544.351528] intel_spi_read(from=2000000, len=400000) [ 544.351528] intel_spi_read(from=2000000, len=400000) End MTD read With this change: Start MTD read [ 21.942922] intel_spi_read(from=1c00000, len=400000) [ 21.942922] intel_spi_read(from=1c00000, len=400000) [ 23.784058] intel_spi_read(from=2000000, len=400000) [ 23.784058] intel_spi_read(from=2000000, len=400000) [ 25.625006] intel_spi_read(from=2400000, len=400000) [ 25.625006] intel_spi_read(from=2400000, len=400000) End MTD read Signed-off-by: Luis Alberto Herrera <luisalberto@google.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20200610224652.64336-1-luisalberto@google.com Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
2020-07-27mtd: spi-nor: update read capabilities for w25q64 and s25fl064kRayagonda Kokatanur2-2/+4
Both w25q64 and s25fl064k nor flash support QUAD and DUAL read command, hence update the same in flash_info table. This is tested on Broadcom Stingray SoC (bcm958742t). s25fl064k and w25q64 share the same JEDEC ID. The search alg will return the first hit, so s25fl064k even for the winbond parts. We should differentiate between these flashes, but it's not in the scope of this patch. Related discussion at: Link: https://lore.kernel.org/patchwork/patch/628090/ Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Link: https://lore.kernel.org/r/20200529071655.739-1-rayagonda.kokatanur@broadcom.com [tudor.ambarus@microchip.com: Update commit message and indicate that s25fl064k and w25q64 share the same JEDEC ID] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
2020-07-27mtd: spi-nor: micron: Add SPI_NOR_DUAL_READ flag on mt25qu02gDavid Clear1-2/+2
The Micron mt25qu02g supports both x2 and x4 transactions. Add the SPI_NOR_DUAL_READ flag to its spi_nor_ids[] table entry. Tested on Pensando SoC hardware with a cadence quadspi controller via drivers/spi/spi-cadence-quadspi.c, in x2 mode at 50MHz. - random data write, erase, read - verified erase operations - random data write, read/compare - verified write/read operations Signed-off-by: David Clear <dac2@pensando.io> Acked-by: Shannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20200720163656.38006-3-dac2@pensando.io Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
2020-07-27mtd: spi-nor: macronix: Add support for mx66u2g45gDavid Clear1-0/+3
The Macronix mx66u2g45g is a 1.8V, 2Gbit (256MB) device that supports x1, x2, or x4 operation. Tested on Pensando SoC hardware with a cadence quadspi controller via drivers/spi/spi-cadence-quadspi.c, in x2 mode at 50MHz. - random data write, erase, read - verified erase operations - random data write, read/compare - verified write/read operations Signed-off-by: David Clear <dac2@pensando.io> Acked-by: Shannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20200720163656.38006-2-dac2@pensando.io Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
2020-07-27mtd: spi-nor: intel-spi: Simulate WRDI commandAlexander Sverdlin1-0/+9
After spi_nor_write_disable() return code checks were introduced in the spi-nor front end intel-spi backend stopped to work because WRDI was never supported and always failed. Just pretend it was sucessful and ignore the command itself. HW sequencer shall do the right thing automatically, while with SW sequencer we cannot do it anyway, because the only tool we had was preopcode and it makes no sense for WRDI. Fixes: bce679e5ae3a ("mtd: spi-nor: Check for errors after each Register Operation") Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/282e1305-fd08-e446-1a22-eb4dff78cfb4@nokia.com Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
2020-07-13mtd: spi-nor: Disable the flash quad mode in spi_nor_restore()Yicong Yang1-0/+2
If the flash's quad mode is enabled, it'll remain in the quad mode when it's removed. If we drive the flash next time in Standard/Dual SPI mode, the QE bit is not cleared and the function of flash's WP# and RESET#/HOLD# have been switched to IO2 and IO3 and are not restored. Disable the Quad mode in spi_nor_restore(), then the flash's QE bit will be cleared when removed. This will make sure the flash always enter the Standard/Dual SPI mode when loaded. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/1594027356-19088-3-git-send-email-yangyicong@hisilicon.com
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-24 09:57:18 +0300