Commit Graph

142 Commits

Author SHA1 Message Date
Brian Norris e5366a266a mtd: spi-nor: support GigaDevice gd25lq64c
Also note the GigaDevice JEDEC ID.

No write-protect support yet, since this flash uses a different status
register layout.

Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
2016-05-10 15:44:18 -07:00
Brian Norris 9648388fc7 mtd: spi-nor: support lock/unlock for a few Winbond chips
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-07 18:01:58 -08:00
Brian Norris 3dd8012a8e mtd: spi-nor: add TB (Top/Bottom) protect support
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-07 18:01:57 -08:00
Brian Norris 76a4707de5 mtd: spi-nor: add SPI_NOR_HAS_LOCK flag
We can't determine this purely by manufacturer type (see commit
67b9bcd369 ("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-07 18:01:57 -08:00
Brian Norris 0618114e2c mtd: spi-nor: use BIT() for flash_info flags
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-07 18:01:56 -08:00
Brian Norris 47b8edbf0d mtd: spi-nor: disallow further writes to SR if WP# is low
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-07 18:01:55 -08:00
Brian Norris f8860802da mtd: spi-nor: make lock/unlock bounds checks more obvious and robust
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-07 18:01:54 -08:00
Brian Norris 4c0dba447e mtd: spi-nor: silently drop lock/unlock for already locked/unlocked region
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-07 18:01:54 -08:00
Brian Norris edf891ef9a mtd: spi-nor: wait for SR_WIP to clear on initial unlock
Fixup a piece leftover by commit 32321e950d ("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-07 18:01:50 -08:00
Yao Yuan a578c4f9eb mtd: spi-nor: fsl-quadspi: add support for layerscape
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-07 11:46:44 -08:00
Yao Yuan e8c034b2fb mtd: spi-nor: fsl-quadspi: add support for ls1021a
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-07 11:46:44 -08:00
Yao Yuan 2012850be8 mtd: spi-nor: fsl-quadspi: add big-endian support
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-07 11:46:43 -08:00
Ezequiel García 4607777c71 mtd: spi-nor: add subsector flag to n25q128a
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-03-04 19:30:38 -08:00
Cyrille Pitchen 3b5394a3cc mtd: spi-nor: remove micron_quad_enable()
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: 548cd3ab54 ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR")
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-02-12 11:35:13 -08:00
Sascha Hauer c082667949 mtd: spi-nor: Add support for s25fl116k
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-02-12 11:34:01 -08:00
Richard Weinberger 15c0be7bec mtd: Fix dependencies for !HAS_IOMEM archs
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-26 11:30:31 -08:00
Geert Uytterhoeven 92752d9974 mtd: mtk-nor: Drop bogus __init from mtk_nor_init()
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-15 09:47:00 -08:00
Ezequiel García 32321e950d mtd: spi-nor: wait until lock/unlock operations are ready
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-06 17:18:34 -08:00
Brian Norris e576330033 mtd: merge MTD development from v4.4 into for-v4.5 development
Small conflict between some bugfixes for 4.4 and some refactoring for
4.5.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-01-05 16:05:56 -08:00
Brian Norris a32d5b726f mtd: spi-nor: fix stm_is_locked_sr() parameters
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-05 16:00:41 -08:00
Brian Norris 67b9bcd369 mtd: spi-nor: fix Spansion regressions (aliased with Winbond)
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: 357ca38d47 ("mtd: spi-nor: support lock/unlock/is_locked for Winbond")
Fixes: c6fc2171b2 ("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>
2016-01-05 16:00:03 -08:00
Bayi Cheng 80e1ca6921 mtd: mtk-nor: adjust sequence of trigger function and assignment function
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-18 15:05:43 -08:00
Fabio Estevam f49289ce64 mtd: spi-nor: Check the return value from read_sr()
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-09 18:15:01 -08:00
Heiner Kallweit d6af26944a mtd: spi-nor: fix error handling in spi_nor_erase
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-04 15:38:47 -08:00
Brian Norris 0f6d3f4097 mtd: mtk-quadspi: drop unnecessary .owner assignment
As of commit 807f16d4db ("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-04 15:31:53 -08:00
Ricardo Ribalda 9b9f1033da mtd: spi-nor: Fix error message with unrecognized JEDEC
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-12-01 10:39:49 -08:00
Bayi Cheng 3ce351b535 mtd: mtk-nor: new Mediatek serial flash controller driver
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-20 17:35:16 -08:00
Andreas Fenkart 0501f2e5ff mtd: spi-nor: mx25l3205d/mx25l6405d: append SECT_4K
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-19 13:37:35 -08:00
Brian Norris c67cbb839d mtd: spi-nor: provide default erase_sector implementation
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-19 13:34:44 -08:00
Brian Norris c98f71d1c0 mtd: fsl-quadspi: possible NULL dereference
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-18 10:31:23 -08:00
Brian Norris 20625dfe03 mtd: spi-nor: remove unnecessary leading space from dbg print
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-16 15:12:30 -08:00
Brian Norris 30069af734 mtd: spi-nor: drop flash_node field
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-11 13:58:56 -08:00
Brian Norris df02c885f8 mtd: spi-nor: drop unnecessary partition parser data
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-11 13:58:51 -08:00
Brian Norris 9c7d787508 mtd: spi-nor: convert to spi_nor_{get, set}_flash_node()
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-11 13:45:24 -08:00
Brian Norris 3e63b26bdd mtd: {nand,spi-nor}: assign MTD of_node
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-11-11 13:45:13 -08:00
Han Xu 04850c4d86 mtd: fsl-quadspi: fix macro collision problems with READ/WRITE
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: d26a22d067 ("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-26 14:44:56 -07:00
Fabio Estevam 01a3c62576 mtd: fsl-quadspi: Include <linux/sizes.h> to avoid build error
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-19 09:50:46 -07:00
Brian Norris d26a22d067 mtd: fsl-quadspi: allow building for other ARCHes with COMPILE_TEST
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-19 09:50:45 -07:00
Brian Norris a5c603a22b mtd: fsl-quadspi: fix printk() format warning for size_t
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-19 09:50:45 -07:00
Brian Norris a23eb34198 mtd: spi-nor: add DUAL_READ for w25q{32,64}dw
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-19 09:50:44 -07:00
Brian Norris c6fc2171b2 mtd: spi-nor: disable protection for Winbond flash at startup
In case the flash was locked at boot time.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13 18:22:56 -07:00
Brian Norris 357ca38d47 mtd: spi-nor: support lock/unlock/is_locked for Winbond
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-13 18:22:55 -07:00
Brian Norris 5bf0e69b67 mtd: spi-nor: add mtd_is_locked() support
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-13 18:22:54 -07:00
Brian Norris 62593cf40b mtd: spi-nor: refactor block protection functions
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-13 18:22:54 -07:00
Brian Norris f0d2448e9a mtd: spi-nor: use SNOR_MFR_* instead of CFI_MFR_*
No functional change, just cosmetic.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13 18:22:52 -07:00
Sean Nyekjaer 7c748f5774 mtd: spi-nor: Add support for s25fl004k
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13 12:56:50 -07:00
Sean Nyekjaer aada20cd2b mtd: spi-nor: s25fl204k supports dual I/0
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-10-13 12:56:50 -07:00
Aurelien Chanot f9bcb6dc80 mtd: spi-nor: Add support for Micron n25q032a
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-10-12 18:37:10 -07:00
Brian Norris 4404bd742d mtd: spi-nor: add support for w25q128fw
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-29 13:25:12 -07:00
Furquan Shaikh 09b6a37768 mtd: spi-nor: scale up timeout for full-chip erase
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-29 13:25:09 -07:00