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

mtd: rawnand: qcom: fix memory corruption that causes panic

2019-01-16T21:03:24Z

commit 81d9bdf59092e4755fc4307c93c4589ef0fe2e0f upstream. This patch fixes a memory corruption that occurred in the qcom-nandc driver since it was converted to nand_scan(). On boot, an affected device will panic from a NPE at a weird place: | Unable to handle kernel NULL pointer dereference at virtual address 0 | pgd = (ptrval) | [00000000] *pgd=00000000 | Internal error: Oops: 80000005 [#1] SMP ARM | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.9 #0 | Hardware name: Generic DT based system | PC is at (null) | LR is at nand_block_isbad+0x90/0xa4 | pc : [<00000000>] lr : [] psr: 80000013 | sp : cf839d40 ip : 00000000 fp : cfae9e20 | r10: cf815810 r9 : 00000000 r8 : 00000000 | r7 : 00000000 r6 : 00000000 r5 : 00000001 r4 : cf815810 | r3 : 00000000 r2 : cfae9810 r1 : ffffffff r0 : cf815810 | Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none | Control: 10c5387d Table: 8020406a DAC: 00000051 | Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) | [] (nand_block_isbad) from [] | [] (allocate_partition) from [] | [] (add_mtd_partitions) from [] | [] (parse_mtd_partitions) from [] | [] (mtd_device_parse_register) from [] | [] (qcom_nandc_probe) from [] The problem is that the nand_scan()'s qcom_nand_attach_chip callback is updating the nandc->max_cwperpage from 1 to 4. This causes the sg_init_table of clear_bam_transaction() in the driver's qcom_nandc_block_bad() to memset much more than what was initially allocated by alloc_bam_transaction(). This patch restores the old behavior by reallocating the shared bam transaction alloc_bam_transaction() after the chip was identified, but before mtd_device_parse_register() (which is an alias for mtd_device_register() - see panic) gets called. This fixes the corruption and the driver is working again. Cc: stable@vger.kernel.org Fixes: 6a3cec64f18c ("mtd: rawnand: qcom: convert driver to nand_scan()") Signed-off-by: Christian Lamparter Acked-by: Miquel Raynal Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: omap2: Pass the parent of pdev to dma_request_chan()

2019-01-09T16:45:52Z

commit 9b432630e0150b777c423fdef6a7b8d17dfa70b6 upstream. Commit e1e6255c311b ("mtd: rawnand: omap2: convert driver to nand_scan()") moved part of the init code in the ->attach_chip hook and at the same time changed the struct device object passed to dma_request_chan() (&pdev->dev instead of pdev->dev.parent). Fixes: e1e6255c311b ("mtd: rawnand: omap2: convert driver to nand_scan()") Reported-by: Alexander Sverdlin Cc: Signed-off-by: Boris Brezillon Tested-by: Alexander Sverdlin Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: Fix JEDEC detection

2019-01-09T16:45:52Z

commit b637ef779575a977068025f842ecd480a9671f3f upstream. nand_jedec_detect() should return 1 when the PARAM page parsing succeeds, otherwise the core considers JEDEC detection failed and falls back to ID-based detection. Fixes: 480139d9229e ("mtd: rawnand: get rid of the JEDEC parameter page in nand_chip") Cc: Signed-off-by: Boris Brezillon Acked-by: Miquel Raynal Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: marvell: prevent timeouts on a loaded machine

2019-01-09T16:45:52Z

commit cafb56dd741e61c99709bcd2b193a9a1d36def3b upstream. marvell_nfc_wait_op() waits for completion during 'timeout_ms' milliseconds before throwing an error. While the logic is fine, the value of 'timeout_ms' is given by the core and actually correspond to the maximum time the NAND chip will take to complete the operation. Assuming there is no overhead in the propagation of the interrupt signal to the the NAND controller (through the Ready/Busy line), this delay does not take into account the latency of the operating system. For instance, for a page write, the delay given by the core is rounded up to 1ms. Hence, when the machine is over loaded, there is chances that this timeout will be reached. There are two ways to solve this issue that are not incompatible: 1/ Enlarge the timeout value (if so, how much?). 2/ Check after the waiting method if we did not miss any interrupt because of the OS latency (an interrupt is still pending). In this case, we assume the operation exited successfully. We choose the second approach that is a must in all cases, with the possibility to also modify the timeout value to be, e.g. at least 1 second in all cases. Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

mtd: atmel-quadspi: disallow building on ebsa110

2019-01-09T16:45:52Z

commit 2a9d92fb3a1282a4659f1bb6d5684018846537b7 upstream. I ran into a link-time error with the atmel-quadspi driver on the EBSA110 platform: drivers/mtd/built-in.o: In function `atmel_qspi_run_command': :(.text+0x1ee3c): undefined reference to `_memcpy_toio' :(.text+0x1ee48): undefined reference to `_memcpy_fromio' The problem is that _memcpy_toio/_memcpy_fromio are not available on that platform, and we have to prevent building the driver there. In case we want to backport this to older kernels: between linux-4.8 and linux-4.20, the Kconfig entry was in drivers/mtd/spi-nor/Kconfig but had the same problem. Link: https://lore.kernel.org/patchwork/patch/812860/ Fixes: 161aaab8a067 ("mtd: atmel-quadspi: add driver for Atmel QSPI controller") Signed-off-by: Arnd Bergmann Reviewed-by: Boris Brezillon Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

ubi: Do not drop UBI device reference before using

2018-12-13T21:09:44Z

The UBI device reference is dropped but then the device is used as a parameter of ubi_err. The bug is introduced in changing ubi_err's behavior. The old ubi_err does not require a UBI device as its first parameter, but the new one does. Fixes: 32608703310 ("UBI: Extend UBI layer debug/messaging capabilities") Signed-off-by: Pan Bian Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger

ubi: Put MTD device after it is not used

2018-12-13T21:09:32Z

The MTD device reference is dropped via put_mtd_device, however its field ->index is read and passed to ubi_msg. To fix this, the patch moves the reference dropping after calling ubi_msg. Signed-off-by: Pan Bian Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger

mtd: nand: Fix memory allocation in nanddev_bbt_init()

2018-11-28T14:41:50Z

Fix the size of the buffer allocated to store the in-memory BBT. This bug was previously hidden by a different bug, that was fixed in commit d098093ba06e ("mtd: nand: Fix nanddev_neraseblocks()"). Fixes: 9c3736a3de21 ("mtd: nand: Add core infrastructure to deal with NAND devices") Cc: Signed-off-by: Frieder Schrempf Acked-by: Miquel Raynal Signed-off-by: Boris Brezillon

mtd: spi-nor: fix erase_type array to indicate current map conf

2018-11-28T08:00:00Z

BFPT advertises all the erase types supported by all the possible map configurations. Mask out the erase types that are not supported by the current map configuration. Backward compatibility test done on sst26vf064b. Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table") Reported-by: Alexander Sverdlin Signed-off-by: Tudor Ambarus Tested-by: Alexander Sverdlin Signed-off-by: Boris Brezillon

mtd: spi-nor: fix selection of uniform erase type in flexible conf

2018-11-20T13:26:59Z

There are uniform, non-uniform and flexible erase flash configurations. The non-uniform erase types, are the erase types that can _not_ erase the entire flash by their own. As the code was, in case flashes had flexible erase capabilities (support both uniform and non-uniform erase types in the same flash configuration) and supported multiple uniform erase type sizes, the code did not sort the uniform erase types, and could select a wrong erase type size. Sort the uniform erase mask in case of flexible erase flash configurations, in order to select the best uniform erase type size. Uniform, non-uniform, and flexible configurations with just a valid uniform erase type, are not affected by this change. Uniform erase tested on mx25l3273fm2i-08g and sst26vf064B-104i/sn. Non uniform erase tested on sst26vf064B-104i/sn. Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories") Signed-off-by: Tudor Ambarus Signed-off-by: Boris Brezillon