user/sven/linux.git/drivers/mtd, branch v4.19.75

mtd: rawnand: mtk: Fix wrongly assigned OOB buffer pointer issue

2019-09-19T07:09:36Z

commit 336d4b138be2dad372b67a2388e42805c48aaa38 upstream. One main goal of the function mtk_nfc_update_ecc_stats is to check whether sectors are all empty. If they are empty, set these sectors's data buffer and OOB buffer as 0xff. But now, the sector OOB buffer pointer is wrongly assigned. We always do memset from sector 0. To fix this issue, pass start sector number to make OOB buffer pointer be properly assigned. Fixes: 1d6b1e464950 ("mtd: mediatek: driver for MTK Smart Device") Signed-off-by: Xiaolei Li Reviewed-by: Miquel Raynal Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: micron: handle on-die "ECC-off" devices correctly

2019-08-06T17:06:54Z

commit 8493b2a06fc5b77ef5c579dc32b12761f7b7a84c upstream. Some devices are not supposed to support on-die ECC but experience shows that internal ECC machinery can actually be enabled through the "SET FEATURE (EFh)" command, even if a read of the "READ ID Parameter Tables" returns that it is not. Currently, the driver checks the "READ ID Parameter" field directly after having enabled the feature. If the check fails it returns immediately but leaves the ECC on. When using buggy chips like MT29F2G08ABAGA and MT29F2G08ABBGA, all future read/program cycles will go through the on-die ECC, confusing the host controller which is supposed to be the one handling correction. To address this in a common way we need to turn off the on-die ECC directly after reading the "READ ID Parameter" and before checking the "ECC status". Cc: stable@vger.kernel.org Fixes: dbc44edbf833 ("mtd: rawnand: micron: Fix on-die ECC detection logic") Signed-off-by: Marco Felsch Reviewed-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: spinand: read returns badly if the last page has bitflips

2019-07-26T07:14:30Z

commit b83408b580eccf8d2797cd6cb9ae42c2a28656a7 upstream. In case of the last page containing bitflips (ret > 0), spinand_mtd_read() will return that number of bitflips for the last page while it should instead return max_bitflips like it does when the last page read returns with 0. Signed-off-by: Weixiong Liao Reviewed-by: Boris Brezillon Reviewed-by: Frieder Schrempf Cc: stable@vger.kernel.org Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: mtk: Correct low level time calculation of r/w cycle

2019-07-26T07:14:30Z

commit e1884ffddacc0424d7e785e6f8087bd12f7196db upstream. At present, the flow of calculating AC timing of read/write cycle in SDR mode is that: At first, calculate high hold time which is valid for both read and write cycle using the max value between tREH_min and tWH_min. Secondly, calculate WE# pulse width using tWP_min. Thridly, calculate RE# pulse width using the bigger one between tREA_max and tRP_min. But NAND SPEC shows that Controller should also meet write/read cycle time. That is write cycle time should be more than tWC_min and read cycle should be more than tRC_min. Obviously, we do not achieve that now. This patch corrects the low level time calculation to meet minimum read/write cycle time required. After getting the high hold time, WE# low level time will be promised to meet tWP_min and tWC_min requirement, and RE# low level time will be promised to meet tREA_max, tRP_min and tRC_min requirement. Fixes: edfee3619c49 ("mtd: nand: mtk: add ->setup_data_interface() hook") Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Xiaolei Li Reviewed-by: Miquel Raynal Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: spinand: macronix: Fix ECC Status Read

2019-06-11T10:20:50Z

commit f4cb4d7b46f6409382fd981eec9556e1f3c1dc5d upstream. The datasheet specifies the upper four bits are reserved. Testing on real hardware shows that these bits can indeed be nonzero. Signed-off-by: Emil Lenngren Reviewed-by: Boris Brezillon Signed-off-by: Miquel Raynal Cc: Christian Lamparter Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: intel-spi: Avoid crossing 4K address boundary on read/write

2019-05-22T05:37:41Z

commit 2b75ebeea6f4937d4d05ec4982c471cef9a29b7f upstream. It was observed that reads crossing 4K address boundary are failing. This limitation is mentioned in Intel documents: Intel(R) 9 Series Chipset Family Platform Controller Hub (PCH) Datasheet: "5.26.3 Flash Access Program Register Access: * Program Register Accesses are not allowed to cross a 4 KB boundary..." Enhanced Serial Peripheral Interface (eSPI) Interface Base Specification (for Client and Server Platforms): "5.1.4 Address For other memory transactions, the address may start or end at any byte boundary. However, the address and payload length combination must not cross the naturally aligned address boundary of the corresponding Maximum Payload Size. It must not cross a 4 KB address boundary." Avoid this by splitting an operation crossing the boundary into two operations. Fixes: 8afda8b26d01 ("spi-nor: Add support for Intel SPI serial flash controller") Cc: stable@vger.kernel.org Reported-by: Romain Porte Tested-by: Pascal Fabreges Signed-off-by: Alexander Sverdlin Reviewed-by: Tudor Ambarus Acked-by: Mika Westerberg Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: gpmi: fix MX28 bus master lockup problem

2019-02-15T07:10:10Z

commit d5d27fd9826b59979b184ec288e4812abac0e988 upstream. Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft reset may cause bus master lock up") for MX28 too. It has the same problem. Observed problem: once per 100,000+ MX28 reboots NAND read failed on DMA timeout errors: [ 1.770823] UBI: attaching mtd3 to ubi0 [ 2.768088] gpmi_nand: DMA timeout, last DMA :1 [ 3.958087] gpmi_nand: BCH timeout, last DMA :1 [ 4.156033] gpmi_nand: Error in ECC-based read: -110 [ 4.161136] UBI warning: ubi_io_read: error -110 while reading 64 bytes from PEB 0:0, read only 0 bytes, retry [ 4.171283] step 1 error [ 4.173846] gpmi_nand: Chip: 0, Error -1 Without BCH soft reset we successfully executed 1,000,000 MX28 reboots. I have a quote from NXP regarding this problem, from July 18th 2016: "As the i.MX23 and i.MX28 are of the same generation, they share many characteristics. Unfortunately, also the erratas may be shared. In case of the documented erratas and the workarounds, you can also apply the workaround solution of one device on the other one. This have been reported, but I’m afraid that there are not an estimated date for updating the Errata documents. Please accept our apologies for any inconveniences this may cause." Fixes: 6f2a6a52560a ("mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems") Cc: stable@vger.kernel.org Signed-off-by: Manfred Schlaegl Signed-off-by: Martin Kepplinger Reviewed-by: Miquel Raynal Reviewed-by: Fabio Estevam Acked-by: Han Xu Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

mtd: spinand: Fix the error/cleanup path in spinand_init()

2019-02-15T07:10:10Z

commit c3c7dbf4887ab3ed9d611cd1f6e16937f8700743 upstream. The manufacturer specific initialization has already been done when block unlocking takes place, and if anything goes wrong during this procedure we should call spinand_manufacturer_cleanup(). Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: Signed-off-by: Boris Brezillon Acked-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: spinand: Handle the case where PROGRAM LOAD does not reset the cache

2019-02-15T07:10:10Z

commit 13c15e07eedf26092054c8c71f2f47edb8388310 upstream. Looks like PROGRAM LOAD (AKA write cache) does not necessarily reset the cache content to 0xFF (depends on vendor implementation), so we must fill the page cache entirely even if we only want to program the data portion of the page, otherwise we might corrupt the BBM or user data previously programmed in OOB area. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Reported-by: Stefan Roese Cc: Signed-off-by: Boris Brezillon Tested-by: Stefan Roese Reviewed-by: Stefan Roese Acked-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: Make sure mtd->erasesize is valid even if the partition is of size 0

2019-02-15T07:10:10Z

commit ad4635153034c20c6f6e211e2ed3fd38b658649a upstream. Commit 33f45c44d68b ("mtd: Do not allow MTD devices with inconsistent erase properties") introduced a check to make sure ->erasesize and ->_erase values are consistent with the MTD_NO_ERASE flag. This patch did not take the 0 bytes partition case into account which can happen when the defined partition is outside the flash device memory range. Fix that by setting the partition erasesize to the parent erasesize. Fixes: 33f45c44d68b ("mtd: Do not allow MTD devices with inconsistent erase properties") Reported-by: Geert Uytterhoeven Cc: Cc: Geert Uytterhoeven Signed-off-by: Boris Brezillon Tested-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman