The spi-nor write loop assumes that what is passed to the hardware
driver write() is what gets written.

When write() writes less than page size at once data is dropped on the
floor. Check the amount of data writen and exit if it does not match
requested amount.
Signed-off-by: NMichal Suchanek <hramrach@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NMichal Suchanek <hramrach@gmail.com>
Tested-by: NMichal Suchanek <hramrach@gmail.com>

Do not pass retlen to hardware driver read/write functions. Update it in
spi-nor generic driver instead.
Signed-off-by: NMichal Suchanek <hramrach@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NMichal Suchanek <hramrach@gmail.com>
Tested-by: NMichal Suchanek <hramrach@gmail.com>

SPI NOR hardware drivers now return useful value from their write
functions so check them.
Signed-off-by: NMichal Suchanek <hramrach@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NMichal Suchanek <hramrach@gmail.com>
Tested-by: NMichal Suchanek <hramrach@gmail.com>

Change the return value of spi-nor device read and write methods to
allow returning amount of data transferred and errors as
read(2)/write(2) does.

Also, start handling positive returns in spi_nor_read(), since we want
to convert drivers to start returning the read-length both via *retlen
and the return code. (We don't need to do the same transition process
for spi_nor_write(), since ->write() didn't used to have a return code
at all.)
Signed-off-by: NMichal Suchanek <hramrach@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NMichal Suchanek <hramrach@gmail.com>
Tested-by: NMichal Suchanek <hramrach@gmail.com>

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: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NMarek Vasut <marex@denx.de>

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: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

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: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

We can't determine this purely by manufacturer type (see commit
67b9bcd3 ("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: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

It's a little easier to read and make sure there are no collisions
(IMO).
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

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: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

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: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

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: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

Fixup a piece leftover by commit 32321e95 ("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: NBrian Norris <computersforpeace@gmail.com>
Cc: Stas Sergeev <stsp@users.sourceforge.net>
Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

Micron n25q128axx support subsector (4K) erase so let's update the flags.
Tested on n25q128a13.
Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Fixes: 548cd3ab ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR")
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The Spansion s25fl116k is a 16MBit NOR Flash supporting dual and
quad read operations.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NStas Sergeev <stsp@list.ru>
Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

stm_is_locked_sr() takes the status register (SR) value as the last
parameter, not the second.
Reported-by: NBayi Cheng <bayi.cheng@mediatek.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Bayi Cheng <bayi.cheng@mediatek.com>

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: 357ca38d ("mtd: spi-nor: support lock/unlock/is_locked for Winbond")
Fixes: c6fc2171 ("mtd: spi-nor: disable protection for Winbond flash at startup")
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reported-by: NFelix Fietkau <nbd@openwrt.org>
Cc: Felix Fietkau <nbd@openwrt.org>

We should better check the return value from read_sr() and
propagate it in the case of error.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

according datasheet both chips can erase 4kByte sectors individually
Signed-off-by: NAndreas Fenkart <andreas.fenkart@dev.digitalstrom.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NBrian Norris <computersforpeace@gmail.com>

As Cyrille noted [1], this line is wrong.

[1] http://lists.infradead.org/pipermail/linux-mtd/2015-September/061725.htmlSigned-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Cyrille Pitchen <cyrille.pitchen@atmel.com>

We can just alias to the MTD of_node.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

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: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

We should pass along our flash DT node to the MTD layer, so it can set
up ofpart for us.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

These flash support dual and quad read. Tested dual read on the 32 Mbit
version.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

In case the flash was locked at boot time.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Many other flash share the same features as ST Micro. I've tested some
Winbond flash, so add them.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This enables ioctl(MEMISLOCKED). Status can now be reported in the
mtdinfo or flash_lock utilities found in mtd-utils.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NBrian Norris <computersforpeace@gmail.com>

No functional change, just cosmetic.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NSean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NSean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NAurelien Chanot <chanot.a@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Tested only with single I/O, but the datasheet says it supports dual and
quad.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NFurquan Shaikh <furquan@google.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

It is a 512KiB flash with 4 KiB erase sectors.
Signed-off-by: NYuan Yao <yao.yuan@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>