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

mtd: mtd_oobtest: Handle bitflips during reads

2018-04-12T10:31:13+00:00

[ Upstream commit 12663b442e5ac5aa3d6097cd3f287c71ba46d26e ]

Reads from NAND devices usually trigger bitflips, this is an expected
behavior. While bitflips are under a given threshold, the MTD core
returns 0. However, when the number of corrected bitflips is above this
same threshold, -EUCLEAN is returned to inform the upper layer that this
block is slightly dying and soon the ECC engine will be overtaken so
actions should be taken to move the data out of it.

This particular condition should not be treated like an error and the
test should continue.

Signed-off-by: Miquel Raynal 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mtd: nand: atmel: Fix get_sectorsize() function

2018-04-08T12:27:33+00:00

commit 2b1b1b4ac716fd929a2d221bd4ade62263bed915 upstream.

get_sectorsize() was not using the appropriate macro to extract the
ECC sector size from the config cache, which led to buggy ECC when
using 1024 byte sectors.

Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
Cc: 
Reported-by: Olivier Schonken 
Signed-off-by: Boris Brezillon 
Reviewed-by: Richard Weinberger 
Acked-by: Nicolas Ferre 
Tested-by: Olivier Schonken 
Signed-off-by: Greg Kroah-Hartman

mtd: jedec_probe: Fix crash in jedec_read_mfr()

2018-04-08T12:27:32+00:00

commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.

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: Greg Kroah-Hartman

mtd: nand: fsl_ifc: Read ECCSTAT0 and ECCSTAT1 registers for IFC 2.0

2018-03-28T16:23:01+00:00

commit 6b00c35138b404be98b85f4a703be594cbed501c upstream.

Due to missing information in Hardware manual, current
implementation doesn't read ECCSTAT0 and ECCSTAT1 registers
for IFC 2.0.

Add support to read ECCSTAT0 and ECCSTAT1 registers during
ecccheck for IFC 2.0.

Fixes: 656441478ed5 ("mtd: nand: ifc: Fix location of eccstat registers for IFC V1.0")
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Jagdish Gediya 
Reviewed-by: Prabhakar Kushwaha 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: nand: fsl_ifc: Fix eccstat array overflow for IFC ver >= 2.0.0

2018-03-28T16:23:01+00:00

commit 843c3a59997f18060848b8632607dd04781b52d1 upstream.

Number of ECC status registers i.e. (ECCSTATx) has been increased in IFC
version 2.0.0 due to increase in SRAM size. This is causing eccstat
array to over flow.

So, replace eccstat array with u32 variable to make it fail-safe and
independent of number of ECC status registers or SRAM size.

Fixes: bccb06c353af ("mtd: nand: ifc: update bufnum mask for ver >= 2.0.0")
Cc: stable@vger.kernel.org # 3.18+
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Jagdish Gediya 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: nand: fsl_ifc: Fix nand waitfunc return value

2018-03-28T16:23:01+00:00

commit fa8e6d58c5bc260f4369c6699683d69695daed0a upstream.

As per the IFC hardware manual, Most significant 2 bytes in
nand_fsr register are the outcome of NAND READ STATUS command.

So status value need to be shifted and aligned as per the nand
framework requirement.

Fixes: 82771882d960 ("NAND Machine support for Integrated Flash Controller")
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Jagdish Gediya 
Reviewed-by: Prabhakar Kushwaha 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtdchar: fix usage of mtd_ooblayout_ecc()

2018-03-28T16:23:01+00:00

commit 6de564939e14327148e31ddcf769e34105176447 upstream.

Section was not properly computed. The value of OOB region definition is
always ECC section 0 information in the OOB area, but we want to get all
the ECC bytes information, so we should call
mtd_ooblayout_ecc(mtd, section++, &oobregion) until it returns -ERANGE.

Fixes: c2b78452a9db ("mtd: use mtd_ooblayout_xxx() helpers where appropriate")
Cc: 
Signed-off-by: OuYang ZhiZhong 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: nand: ifc: update bufnum mask for ver >= 2.0.0

2018-03-19T08:09:53+00:00

[ Upstream commit bccb06c353af3764ca86d9da47652458e6c2eb41 ]

Bufnum mask is used to calculate page position in the internal SRAM.

As IFC version 2.0.0 has 16KB of internal SRAM as compared to older
versions which had 8KB. Hence bufnum mask needs to be updated.

Signed-off-by: Jagdish Gediya 
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

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

2018-03-19T08:09:52+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 
Signed-off-by: Greg Kroah-Hartman

mtd: nand: vf610: set correct ooblayout

2018-02-22T14:40:10+00:00

commit ea56fb282368ea08c2a313af6b55cb597aec4db1 upstream.

With commit 3cf32d180227 ("mtd: nand: vf610: switch to
mtd_ooblayout_ops") the driver started to use the NAND cores
default large page ooblayout. However, shortly after commit
6a623e076944 ("mtd: nand: add ooblayout for old hamming layout")
changed the default layout to the old hamming layout, which is
not what vf610_nfc is using. Specify the default large page
layout explicitly.

Fixes: 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout")
Cc:  # v4.12+
Signed-off-by: Stefan Agner 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman