linux-stable.git/drivers/mtd, branch linux-4.17.y

mtd: dataflash: Use ULL suffix for 64-bit constants

2018-08-24T11:06:47+00:00

[ Upstream commit cbdceb9b3e1928554fffd0d889adf2d0d8edee4d ]

With gcc 4.1.2 when compiling for 32-bit:

    drivers/mtd/devices/mtd_dataflash.c:736: warning: integer constant is too large for ‘long’ type
    drivers/mtd/devices/mtd_dataflash.c:737: warning: integer constant is too large for ‘long’ type

Add the missing "ULL" suffixes to fix this.

Fixes: 67e4145ebf2c161d ("mtd: dataflash: Add flash_info for AT45DB641E")
Signed-off-by: Geert Uytterhoeven 
Acked-by: Andrey Smirnov 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: fsl_ifc: fix FSL NAND driver to read all ONFI parameter pages

2018-08-03T05:47:53+00:00

[ Upstream commit a75bbe71a27875fdc61cde1af6d799037cef6bed ]

Per ONFI specification (Rev. 4.0), if the CRC of the first parameter page
read is not valid, the host should read redundant parameter page copies.
Fix FSL NAND driver to read the two redundant copies which are mandatory
in the specification.

Signed-off-by: Jane Wan 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: cadence-quadspi: Fix direct mode write timeouts

2018-07-17T09:48:25+00:00

commit aa7eee8a143a7e8b530eb1e75fb86cae793d1e21 upstream.

Sometimes when writing large size files to flash in direct/memory mapped
mode, it is seen that flash write enable command times out with error:
[  503.146293] cadence-qspi 47040000.ospi: Flash command execution timed out.

This is because, we need to make sure previous direct write operation
is complete by polling for IDLE bit in CONFIG_REG before starting the
next operation.

Fix this by polling for IDLE bit after memory mapped write.

Fixes: a27f2eaf2b27 ("mtd: spi-nor: cadence-quadspi: Add support for direct access mode")
Cc: stable@vger.kernel.org
Signed-off-by: Vignesh R 
Reviewed-by: Marek Vasut 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Change erase functions to check chip good only

2018-07-11T14:31:34+00:00

commit 79ca484b613041ca223f74b34608bb6f5221724b upstream.

Currently the functions use to check both chip ready and good.
But the chip ready is not enough to check the operation status.
So change this to check the chip good instead of this.
About the retry functions to make sure the error handling remain it.

Signed-off-by: Tokunori Ikegami 
Reviewed-by: Joakim Tjernlund 
Cc: Chris Packham 
Cc: Brian Norris 
Cc: David Woodhouse 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-mtd@lists.infradead.org
Cc: stable@vger.kernel.org
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Change erase functions to retry for error

2018-07-11T14:31:34+00:00

commit 45f75b8a919a4255f52df454f1ffdee0e42443b2 upstream.

For the word write functions it is retried for error.
But it is not implemented to retry for the erase functions.
To make sure for the erase functions change to retry as same.

This is needed to prevent the flash erase error caused only once.
It was caused by the error case of chip_good() in the do_erase_oneblock().
Also it was confirmed on the MACRONIX flash device MX29GL512FHT2I-11G.
But the error issue behavior is not able to reproduce at this moment.
The flash controller is parallel Flash interface integrated on BCM53003.

Signed-off-by: Tokunori Ikegami 
Reviewed-by: Joakim Tjernlund 
Cc: Chris Packham 
Cc: Brian Norris 
Cc: David Woodhouse 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-mtd@lists.infradead.org
Cc: stable@vger.kernel.org
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Change definition naming to retry write operation

2018-07-11T14:31:33+00:00

commit 85a82e28b023de9b259a86824afbd6ba07bd6475 upstream.

The definition can be used for other program and erase operations also.
So change the naming to MAX_RETRIES from MAX_WORD_RETRIES.

Signed-off-by: Tokunori Ikegami 
Reviewed-by: Joakim Tjernlund 
Cc: Chris Packham 
Cc: Brian Norris 
Cc: David Woodhouse 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-mtd@lists.infradead.org
Cc: stable@vger.kernel.org
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

ubi: fastmap: Correctly handle interrupted erasures in EBA

2018-07-03T09:27:03+00:00

commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.

Fastmap cannot track the LEB unmap operation, therefore it can
happen that after an interrupted erasure the mapping still looks
good from Fastmap's point of view, while reading from the PEB will
cause an ECC error and confuses the upper layer.

Instead of teaching users of UBI how to deal with that, we read back
the VID header and check for errors. If the PEB is empty or shows ECC
errors we fixup the mapping and schedule the PEB for erasure.

Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Cc: 
Reported-by: martin bayern 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

ubi: fastmap: Cancel work upon detach

2018-07-03T09:27:03+00:00

commit 6e7d80161066c99d12580d1b985cb1408bb58cf1 upstream.

Ben Hutchings pointed out that 29b7a6fa1ec0 ("ubi: fastmap: Don't flush
fastmap work on detach") does not really fix the problem, it just
reduces the risk to hit the race window where fastmap work races against
free()'ing ubi->volumes[].

The correct approach is making sure that no more fastmap work is in
progress before we free ubi data structures.
So we cancel fastmap work right after the ubi background thread is
stopped.
By setting ubi->thread_enabled to zero we make sure that no further work
tries to wake the thread.

Fixes: 29b7a6fa1ec0 ("ubi: fastmap: Don't flush fastmap work on detach")
Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system")
Cc: stable@vger.kernel.org
Cc: Ben Hutchings 
Cc: Martin Townsend 

Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Avoid walking all chips when unlocking.

2018-07-03T09:26:58+00:00

commit f1ce87f6080b1dda7e7b1eda3da332add19d87b9 upstream.

cfi_ppb_unlock() walks all flash chips when unlocking sectors,
avoid walking chips unaffected by the unlock operation.

Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking")
Cc: stable@vger.kernel.org
Signed-off-by: Joakim Tjernlund 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Fix unlocking requests crossing a chip boudary

2018-07-03T09:26:58+00:00

commit 0cd8116f172eed018907303dbff5c112690eeb91 upstream.

The "sector is in requested range" test used to determine whether
sectors should be re-locked or not is done on a variable that is reset
everytime we cross a chip boundary, which can lead to some blocks being
re-locked while the caller expect them to be unlocked.
Fix the check to make sure this cannot happen.

Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking")
Cc: stable@vger.kernel.org
Signed-off-by: Joakim Tjernlund 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman