summaryrefslogtreecommitdiff
path: root/drivers/mtd/spi-nor
AgeCommit message (Collapse)Author
2016-03-07mtd: spi-nor: support lock/unlock for a few Winbond chipsBrian Norris
These are recent Winbond models that are known to have lock/unlock support via writing the Status Register, and that also support the TB (Top/Bottom) protection bit. Tested on w25q32dw. [Note on style: these entries are getting pretty long lines, so I picked a style that seems reasonable for splitting up the flags separate from the other mostly-similar fields.] Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
2016-03-07mtd: spi-nor: add TB (Top/Bottom) protect supportBrian Norris
Some flash support a bit in the status register that inverts protection so that it applies to the bottom of the flash, not the top. This yields additions to the protection range table, as noted in the comments. Because this feature is not universal to all flash that support lock/unlock, control it via a new flag. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
2016-03-07mtd: spi-nor: add SPI_NOR_HAS_LOCK flagBrian Norris
We can't determine this purely by manufacturer type (see commit 67b9bcd36906 ("mtd: spi-nor: fix Spansion regressions (aliased with Winbond)")), and it's not autodetectable by anything like SFDP. So make a new flag for it. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
2016-03-07mtd: spi-nor: use BIT() for flash_info flagsBrian Norris
It's a little easier to read and make sure there are no collisions (IMO). Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
2016-03-07mtd: spi-nor: disallow further writes to SR if WP# is lowBrian Norris
Locking the flash is most useful if it provides real hardware security. Otherwise, it's little more than a software permission bit. A reasonable use case that provides real HW security might be like follows: (1) hardware WP# is deasserted (2) program flash (3) flash range is protected via status register (4) hardware WP# is asserted (5) flash protection range can no longer be changed, until WP# is deasserted In this way, flash protection is co-owned by hardware and software. Now, one would expect to be able to perform step (3) with ioctl(MEMLOCK), except that the spi-nor driver does not set the Status Register Protect bit (a.k.a. Status Register Write Disable (SRWD)), so even though the range is now locked, it does not satisfy step (5) -- it can still be changed by a call to ioctl(MEMUNLOCK). So, let's enable status register protection after the first lock command, and disable protection only when the flash is fully unlocked. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
2016-03-07mtd: spi-nor: make lock/unlock bounds checks more obvious and robustBrian Norris
There are a few different corner cases to the current logic that seem undesirable: * mtd_lock() with offs==0 trips a bounds issue on ofs - mtd->erasesize < 0 * mtd_unlock() on the middle of a flash that is already unlocked will return -EINVAL * probably other corner cases So, let's stop doing "smart" checks like "check the block below us", let's just do the following: (a) pass only non-negative offsets/lengths to stm_is_locked_sr() (b) add a similar stm_is_unlocked_sr() function, so we can check if the *entire* range is unlocked (and not just whether some part of it is unlocked) Then armed with (b), we can make lock() and unlock() much more symmetric: (c) short-circuit the procedure if there is no work to be done, and (d) check the entire range above/below This also aligns well with the structure needed for proper TB (Top/Bottom) support. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
2016-03-07mtd: spi-nor: silently drop lock/unlock for already locked/unlocked regionBrian Norris
If, for instance, the entire flash is already unlocked and I try to mtd_unlock() the entire device, I don't expect to see an EINVAL error. It should just silently succeed. Ditto for mtd_lock(). Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
2016-03-07mtd: spi-nor: wait for SR_WIP to clear on initial unlockBrian Norris
Fixup a piece leftover by commit 32321e950d8a ("mtd: spi-nor: wait until lock/unlock operations are ready"). That commit made us wait for the WIP bit to settle after lock/unlock operations, but it missed the open-coded "unlock" that happens at probe() time. We should probably have this code utilize the unlock() routines in the future, to avoid duplication, but unfortunately, flash which need to be unlocked don't all have a proper ->flash_unlock() callback. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Cc: Stas Sergeev <stsp@users.sourceforge.net> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
2016-03-07mtd: spi-nor: fsl-quadspi: add support for layerscapeYao Yuan
LS1043a and LS2080A in the Layerscape family also support Freescale Quad SPI, make Quad SPI selectable for these hardwares. Signed-off-by: Yuan Yao <yao.yuan@nxp.com> Acked-by: Han xu <han.xu@nxp.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-03-07mtd: spi-nor: fsl-quadspi: add support for ls1021aYao Yuan
LS1021a also support Freescale Quad SPI controller. Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI selectable for LS1021A SOC hardwares. Signed-off-by: Yuan Yao <yao.yuan@nxp.com> Acked-by: Han xu <han.xu@freescale.com> Acked-by: Han xu <han.xu@nxp.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-03-07mtd: spi-nor: fsl-quadspi: add big-endian supportYao Yuan
Add R/W functions for big- or little-endian registers: The qSPI controller's endian is independent of the CPU core's endian. So far, the qSPI have two versions for big-endian and little-endian. Signed-off-by: Yuan Yao <yao.yuan@nxp.com> Acked-by: Han xu <han.xu@freescale.com> Acked-by: Han xu <han.xu@nxp.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-03-04mtd: spi-nor: add subsector flag to n25q128aEzequiel García
Micron n25q128axx support subsector (4K) erase so let's update the flags. Tested on n25q128a13. Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-02-12mtd: spi-nor: remove micron_quad_enable()Cyrille Pitchen
This patch remove the micron_quad_enable() function which force the Quad SPI mode. However, once this mode is enabled, the Micron memory expect ALL commands to use the SPI 4-4-4 protocol. Hence a failure does occur when calling spi_nor_wait_till_ready() right after the update of the Enhanced Volatile Configuration Register (EVCR) in the micron_quad_enable() as the SPI controller driver is not aware about the protocol change. Since there is almost no performance increase using Fast Read 4-4-4 commands instead of Fast Read 1-1-4 commands, we rather keep on using the Extended SPI mode than enabling the Quad SPI mode. Let's take the example of the pretty standard use of 8 dummy cycles during Fast Read operations on 64KB erase sectors: Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the 3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles for the read data; so 131112 clock cycles. On the other hand the Fast Read 4-4-4 would require 2 cycles for the command, then 6 cycles for the 3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles for the read data. So 131088 clock cycles. The theorical bandwidth increase is 0.0%. Now using Fast Read operations on 512byte pages: Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the theorical bandwidth increase is 2.3%. Consecutive reads for non sequential pages is not a relevant use case so The Quad SPI mode is not worth it. mtd_speedtest seems to confirm these figures. Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Fixes: 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR") Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-02-12mtd: spi-nor: Add support for s25fl116kSascha Hauer
The Spansion s25fl116k is a 16MBit NOR Flash supporting dual and quad read operations. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-01-26mtd: Fix dependencies for !HAS_IOMEM archsRichard Weinberger
Not every arch has io memory. So, unbreak the build by fixing the dependencies. Signed-off-by: Richard Weinberger <richard@nod.at> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-01-15mtd: mtk-nor: Drop bogus __init from mtk_nor_init()Geert Uytterhoeven
WARNING: drivers/mtd/spi-nor/mtk-quadspi.o(.text+0x77e): Section mismatch in reference from the function mtk_nor_drv_probe() to the function .init.text:mtk_nor_init() The function mtk_nor_drv_probe() references the function __init mtk_nor_init(). This is often because mtk_nor_drv_probe lacks a __init annotation or the annotation of mtk_nor_init is wrong. Drop the bogus __init from mtk_nor_init() to kill this warning. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-01-06mtd: spi-nor: wait until lock/unlock operations are readyEzequiel García
On Micron and Numonyx devices, the status register write command (WRSR), raises a work-in-progress bit (WIP) on the status register. The datasheets for these devices specify that while the status register write is in progress, the status register WIP bit can still be read to check the end of the operation. This commit adds a wait_till_ready call on lock/unlock operations, which is required for Micron and Numonyx but should be harmless for others. This is needed to prevent applications from issuing erase or program operations before the unlock operation is completed. Reported-by: Stas Sergeev <stsp@list.ru> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-01-05mtd: merge MTD development from v4.4 into for-v4.5 developmentBrian Norris
Small conflict between some bugfixes for 4.4 and some refactoring for 4.5. Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-01-05mtd: spi-nor: fix stm_is_locked_sr() parametersBrian Norris
stm_is_locked_sr() takes the status register (SR) value as the last parameter, not the second. Reported-by: Bayi Cheng <bayi.cheng@mediatek.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Cc: Bayi Cheng <bayi.cheng@mediatek.com>
2016-01-05mtd: spi-nor: fix Spansion regressions (aliased with Winbond)Brian Norris
Spansion and Winbond have occasionally used the same manufacturer ID, and they don't support the same features. Particularly, writing SR=0 seems to break read access for Spansion's s25fl064k. Unfortunately, we don't currently have a way to differentiate these Spansion and Winbond parts, so rather than regressing support for these Spansion flash, let's drop the new Winbond lock/unlock support for now. We can try to address Winbond support during the next release cycle. Original discussion: http://patchwork.ozlabs.org/patch/549173/ http://patchwork.ozlabs.org/patch/553683/ Fixes: 357ca38d4751 ("mtd: spi-nor: support lock/unlock/is_locked for Winbond") Fixes: c6fc2171b249 ("mtd: spi-nor: disable protection for Winbond flash at startup") Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reported-by: Felix Fietkau <nbd@openwrt.org> Cc: Felix Fietkau <nbd@openwrt.org>
2015-12-18mtd: mtk-nor: adjust sequence of trigger function and assignment functionBayi Cheng
Move write data register before excute command to avoid missing first byte write to nor flash Signed-off-by: Bayi Cheng <bayi.cheng@mediatek.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-12-09mtd: spi-nor: Check the return value from read_sr()Fabio Estevam
We should better check the return value from read_sr() and propagate it in the case of error. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-12-04mtd: spi-nor: fix error handling in spi_nor_eraseHeiner Kallweit
The documenting comment of mtd_erase in mtdcore.c states: Device drivers are supposed to call instr->callback() whenever the operation completes, even if it completes with a failure. Currently the callback isn't called in case of failure. Fix this. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-12-04mtd: mtk-quadspi: drop unnecessary .owner assignmentBrian Norris
As of commit 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set"), the MTD core will set this for us. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Cc: Bayi Cheng <bayi.cheng@mediatek.com>
2015-12-01mtd: spi-nor: Fix error message with unrecognized JEDECRicardo Ribalda
The error message was: m25p80 spi32766.0: unrecognized JEDEC id bytes: 00, 0, 0 The new error message: m25p80 spi32766.0: unrecognized JEDEC id bytes: 00, 00, 00 Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-11-20mtd: mtk-nor: new Mediatek serial flash controller driverBayi Cheng
Add spi nor flash driver for mediatek controller Signed-off-by: Bayi Cheng <bayi.cheng@mediatek.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-11-19mtd: spi-nor: mx25l3205d/mx25l6405d: append SECT_4KAndreas Fenkart
according datasheet both chips can erase 4kByte sectors individually Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-11-19mtd: spi-nor: provide default erase_sector implementationBrian Norris
Some spi-nor drivers perform sector erase by duplicating their write_reg() command. Let's not require that the driver fill this out, and provide a default instead. Tested on m25p80.c and Medatek's MT8173 SPI NOR flash driver. Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-11-18mtd: fsl-quadspi: possible NULL dereferenceBrian Norris
It is theoretically possible to probe this driver without a matching device tree, so let's guard against this. Also, use the of_device_get_match_data() helper to make this a bit simpler. Coverity complained about this one. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Han xu <han.xu@freescale.com>
2015-11-16mtd: spi-nor: remove unnecessary leading space from dbg printBrian Norris
As Cyrille noted [1], this line is wrong. [1] http://lists.infradead.org/pipermail/linux-mtd/2015-September/061725.html Signed-off-by: Brian Norris <computersforpeace@gmail.com> Cc: Cyrille Pitchen <cyrille.pitchen@atmel.com>
2015-11-11mtd: spi-nor: drop flash_node fieldBrian Norris
We can just alias to the MTD of_node. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2015-11-11mtd: spi-nor: drop unnecessary partition parser dataBrian Norris
Now that the SPI-NOR/MTD framework pass the 'flash_node' through to the partition parsing code, we don't have to do it ourselves. Also convert to mtd_device_register(), since we don't need the 2nd and 3rd parameters anymore. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2015-11-11mtd: spi-nor: convert to spi_nor_{get, set}_flash_node()Brian Norris
Used semantic patch with 'make coccicheck MODE=patch COCCI=script.cocci': ---8<---- virtual patch @@ struct spi_nor b; struct spi_nor *c; expression d; @@ ( -(b).flash_node = (d) +spi_nor_set_flash_node(&b, d) | -(c)->flash_node = (d) +spi_nor_set_flash_node(c, d) ) ---8<---- And a manual conversion for the one use of spi_nor_get_flash_node(). Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2015-11-11mtd: {nand,spi-nor}: assign MTD of_nodeBrian Norris
We should pass along our flash DT node to the MTD layer, so it can set up ofpart for us. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2015-10-26mtd: fsl-quadspi: fix macro collision problems with READ/WRITEHan Xu
Change the READ/WRITE to FSL_READ/FSL_WRITE to resolve any possible namespace collisions with READ/WRITE macros (e.g., from <linux/fs.h>). Problems have been seen, for example, on mips: >> drivers/mtd/spi-nor/fsl-quadspi.c:186:5: error: 'LUT_0' undeclared (first use in this function) ((LUT_##ins) << INSTR0_SHIFT)) ^ >> drivers/mtd/spi-nor/fsl-quadspi.c:188:30: note: in expansion of macro 'LUT0' On SPARC: drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut': drivers/mtd/spi-nor/fsl-quadspi.c:369:1: error: 'LUT_0' undeclared (first use in this function) drivers/mtd/spi-nor/fsl-quadspi.c:418:1: error: pasting "LUT_" and "(" does not give a valid preprocessing token drivers/mtd/spi-nor/fsl-quadspi.c:418:2: error: implicit declaration of function 'LUT_' And surely on others. Fixes: d26a22d06708 ("mtd: fsl-quadspi: allow building for other ARCHes with COMPILE_TEST") Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Han Xu <b45815@freescale.com> [Brian: rewrote commit description] Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-19mtd: fsl-quadspi: Include <linux/sizes.h> to avoid build errorFabio Estevam
Building for x86 results in the following build errors: drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut': >> drivers/mtd/spi-nor/fsl-quadspi.c:355:21: error: 'SZ_16M' undeclared (first use in this function) if (q->nor_size <= SZ_16M) { ^ drivers/mtd/spi-nor/fsl-quadspi.c:355:21: note: each undeclared identifier is reported only once for each function it appears in drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_read': >> drivers/mtd/spi-nor/fsl-quadspi.c:208:27: error: 'SZ_4M' undeclared (first use in this function) #define QUADSPI_MIN_IOMAP SZ_4M ^ >> drivers/mtd/spi-nor/fsl-quadspi.c:845:25: note: in expansion of macro 'QUADSPI_MIN_IOMAP' q->memmap_len = len > QUADSPI_MIN_IOMAP ? len : QUADSPI_MIN_IOMAP; Explicitly include <linux/sizes.h> to fix the problem. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-19mtd: fsl-quadspi: allow building for other ARCHes with COMPILE_TESTBrian Norris
This driver doesn't actually need ARCH_MXC to compile. Relax the constraints. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Han xu <han.xu@freescale.com>
2015-10-19mtd: fsl-quadspi: fix printk() format warning for size_tBrian Norris
Seen when compile-testing on non-32-bit arch: CC drivers/mtd/spi-nor/fsl-quadspi.o drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_read': drivers/mtd/spi-nor/fsl-quadspi.c:873:2: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t' [-Wformat=] dev_dbg(q->dev, "cmd [%x],read from 0x%p, len:%d\n", ^ Also drop the '0x' prefixing to the '%p' formatter, since %p already knows how to format pointers appropriately. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Han xu <han.xu@freescale.com>
2015-10-19mtd: spi-nor: add DUAL_READ for w25q{32,64}dwBrian Norris
These flash support dual and quad read. Tested dual read on the 32 Mbit version. Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13mtd: spi-nor: disable protection for Winbond flash at startupBrian Norris
In case the flash was locked at boot time. Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13mtd: spi-nor: support lock/unlock/is_locked for WinbondBrian Norris
Many other flash share the same features as ST Micro. I've tested some Winbond flash, so add them. Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13mtd: spi-nor: add mtd_is_locked() supportBrian Norris
This enables ioctl(MEMISLOCKED). Status can now be reported in the mtdinfo or flash_lock utilities found in mtd-utils. Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13mtd: spi-nor: refactor block protection functionsBrian Norris
This code was a bit sloppy, would produce a lot of copy-and-paste, and did not always provide a sensible interface: * It didn't validate the length for LOCK and the offset for UNLOCK, so we were essentially discarding half of the user-supplied data and assuming what they wanted to lock/unlock * It didn't do very good error checking * It didn't make use of the fact that this operation works on power-of-two dimensions So, rewrite this to do proper bit arithmetic rather than a bunch of hard-coded condition tables. Now we have: * More comments on how this was derived * Notes on what is (and isn't) supported * A more exendible function, so we could add support for other protection ranges * More accurate locking - e.g., suppose the top quadrant is locked (75% to 100%); then in the following cases, case (a) will succeed but (b) will not (return -EINVAL): (a) user requests lock 3rd quadrant (50% to 75%) (b) user requests lock 3rd quadrant, minus a few blocks (e.g., 50% to 73%) Case (b) *should* fail, since we'd have to lock blocks that weren't requested. But the old implementation didn't know the difference and would lock the entire second half (50% to 100%) This refactoring work will also help enable the addition of mtd_is_locked() support and potentially the support of bottom boot protection (TB=1). Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13mtd: spi-nor: use SNOR_MFR_* instead of CFI_MFR_*Brian Norris
No functional change, just cosmetic. Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13mtd: spi-nor: Add support for s25fl004kSean Nyekjaer
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13mtd: spi-nor: s25fl204k supports dual I/0Sean Nyekjaer
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-12mtd: spi-nor: Add support for Micron n25q032aAurelien Chanot
The N25Q032A is identical to the N25Q032 except it has a different supply voltage range. Therefore, it has a new JEDEC ID. Signed-off-by: Aurelien Chanot <chanot.a@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-09-29mtd: spi-nor: add support for w25q128fwBrian Norris
Tested only with single I/O, but the datasheet says it supports dual and quad. Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-09-29mtd: spi-nor: scale up timeout for full-chip eraseFurquan Shaikh
This patch fixes timeout issues seen on large NOR flash (e.g., 16MB w25q128fw) when using ioctl(MEMERASE) with offset=0 and length=16M. The input parameters matter because spi_nor_erase() uses a different code path for full-chip erase, where we use the SPINOR_OP_CHIP_ERASE (0xc7) opcode. Fix: use a different timeout for full-chip erase than for other commands. While most operations can be expected to perform relatively similarly across a variety of NOR flash types and sizes (and therefore might as well use a similar timeout to keep things simple), full-chip erase is unique, because the time it typically takes to complete: (1) is much larger than most operations and (2) scales with the size of the flash. Let's base our timeout on the original comments stuck here -- that a 2MB flash requires max 40s to erase. Small survey of a few flash datasheets I have lying around: Chip Size (MB) Max chip erase (seconds) ---- -------- ------------------------ w25q32fw 4 50 w25q64cv 8 30 w25q64fw 8 100 w25q128fw 16 200 s25fl128s 16 ~256 s25fl256s 32 ~512 From this data, it seems plenty sufficient to say we need to wait for 40 seconds for each 2MB of flash. After this change, it might make some sense to decrease the timeout for everything else, as even the most extreme operations (single block erase?) shouldn't take more than a handful of seconds. But for safety, let's leave it as-is. It's only an error case, after all, so we don't exactly need to optimize it. Signed-off-by: Furquan Shaikh <furquan@google.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-09-29mtd: spi-nor: Add support for sst25wf040bYao Yuan
It is a 512KiB flash with 4 KiB erase sectors. Signed-off-by: Yuan Yao <yao.yuan@freescale.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>