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

mtd: cfi: cmdset_0002: Do not allow read/write to suspend erase block.

2018-05-23T01:36:38+00:00

[ Upstream commit 7b70eb14392a7cf505f9b358d06c33b5af73d1e7 ]

Currently it is possible to read and/or write to suspend EB's.
Writing /dev/mtdX or /dev/mtdblockX from several processes may
break the flash state machine.

Taken from cfi_cmdset_0001 driver.

Signed-off-by: Joakim Tjernlund 
Cc: 
Reviewed-by: Richard Weinberger 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin

mtd: cfi: cmdset_0001: Workaround Micron Erase suspend bug.

2018-05-23T01:36:38+00:00

[ Upstream commit 46a16a2283f9e678a4e26829175e0c37a5191860 ]

Some Micron chips does not work well wrt Erase suspend for
boot blocks. This avoids the issue by not allowing Erase suspend
for the boot blocks for the 28F00AP30(1GBit) chip.

Signed-off-by: Joakim Tjernlund 
Cc: 
Reviewed-by: Richard Weinberger 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin

mtd: cfi: cmdset_0001: Do not allow read/write to suspend erase block.

2018-05-23T01:36:38+00:00

[ Upstream commit 6510bbc88e3258631831ade49033537081950605 ]

Currently it is possible to read and/or write to suspend EB's.
Writing /dev/mtdX or /dev/mtdblockX from several processes may
break the flash state machine.

Signed-off-by: Joakim Tjernlund 
Cc: 
Reviewed-by: Richard Weinberger 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin

ubi: Reject MLC NAND

2018-05-23T01:36:32+00:00

[ Upstream commit b5094b7f135be34630e3ea8a98fa215715d0f29d ]

While UBI and UBIFS seem to work at first sight with MLC NAND, you will
most likely lose all your data upon a power-cut or due to read/write
disturb.
In order to protect users from bad surprises, refuse to attach to MLC
NAND.

Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger 
Acked-by: Boris Brezillon 
Acked-by: Artem Bityutskiy 
Signed-off-by: Sasha Levin

ubi: Fix error for write access

2018-05-23T01:36:32+00:00

[ Upstream commit 78a8dfbabbece22bee58ac4cb26cab10e7a19c5d ]

When opening a device with write access, ubiblock_open returns an error
code. Currently, this error code is -EPERM, but this is not the right
value.

The open function for other block devices returns -EROFS when opening
read-only devices with FMODE_WRITE set. When used with dm-verity, the
veritysetup userspace tool is expecting EROFS, and refuses to use the
ubiblock device.

Use -EROFS for ubiblock as well. As a result, veritysetup accepts the
ubiblock device as valid.

Cc: stable@vger.kernel.org
Fixes: 9d54c8a33eec (UBI: R/O block driver on top of UBI volumes)
Signed-off-by: Romain Izard 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

ubi: fastmap: Don't flush fastmap work on detach

2018-05-23T01:36:32+00:00

[ Upstream commit 29b7a6fa1ec07e8480b0d9caf635a4498a438bf4 ]

At this point UBI volumes have already been free()'ed and fastmap can no
longer access these data structures.

Reported-by: Martin Townsend 
Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system")
Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

mtd: jedec_probe: Fix crash in jedec_read_mfr()

2018-05-23T01:33:55+00:00

[ Upstream commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 ]

It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:

Unable to handle kernel paging request at virtual address c4980000
pgd = (ptrval)
[c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : []    lr : [<00000004>]    psr: 60000013
sp : c382dd18  ip : 0000ffff  fp : 00000000
r10: c0626388  r9 : 00020000  r8 : c0626340
r7 : 00000000  r6 : 00000001  r5 : c3a71afc  r4 : c382dd70
r3 : 00000001  r2 : c4900000  r1 : 00000002  r0 : 00080000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 0000397f  Table: 00004000  DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))

Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.

Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
Cc: 
Signed-off-by: Linus Walleij 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin

mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]()

2018-05-23T01:33:46+00:00

[ Upstream commit df467899da0b71465760b4e35127bce837244eee ]

Some drivers (like nand_hynix.c) call ->cmdfunc() with NAND_CMD_NONE
and a column address and expect the controller to only send address
cycles. Right now, the default ->cmdfunc() implementations provided by
the core do not filter out the command cycle in this case and forwards
the request to the controller driver through the ->cmd_ctrl() method.
The thing is, NAND controller drivers can get this wrong and send a
command cycle with a NAND_CMD_NONE opcode and since NAND_CMD_NONE is
-1, and the command field is usually casted to an u8, we end up sending
the 0xFF command which is actually a RESET operation.

Add conditions in nand_command[_lp]() functions to sending the initial
command cycle when command == NAND_CMD_NONE.

Signed-off-by: Miquel Raynal 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin

ubi: Fix race condition between ubi volume creation and udev

2018-03-21T03:49:52+00:00

[ Upstream commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 ]

Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
device creation and udev"), we should make the volume active before
registering it.

Signed-off-by: Clay McClure 
Cc: 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM

2018-03-21T03:49:44+00:00

[ Upstream commit fdf2e821052958a114618a95ab18a300d0b080cb ]

When erased subpages are read then the BCH decoder returns STATUS_ERASED
if they are all empty, or STATUS_UNCORRECTABLE if there are bitflips.
When there are bitflips, we have to set these bits again to show the
upper layers a completely erased page. When a bitflip happens in the
exact byte where the bad block marker is, then this byte is swapped
with another byte in block_mark_swapping(). The correction code then
detects a bitflip in another subpage and no longer corrects the bitflip
where it really happens.

Correct this behaviour by calling block_mark_swapping() after the
bitflips have been corrected.

In our case UBIFS failed with this bug because it expects erased
pages to be really empty:

UBIFS error (pid 187): ubifs_scan: corrupt empty space at LEB 36:118735
UBIFS error (pid 187): ubifs_scanned_corruption: corruption at LEB 36:118735
UBIFS error (pid 187): ubifs_scanned_corruption: first 8192 bytes from LEB 36:118735
UBIFS error (pid 187): ubifs_scan: LEB 36 scanning failed
UBIFS error (pid 187): do_commit: commit failed, error -117

Signed-off-by: Sascha Hauer 
Reviewed-by: Richard Weinberger 
Acked-by: Boris Brezillon 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin