summaryrefslogtreecommitdiff
path: root/drivers/mtd
AgeCommit message (Collapse)AuthorFilesLines
2021-03-04mtd: spi-nor: hisi-sfc: Put child node np on error pathPan Bian1-1/+3
commit fe6653460ee7a7dbe0cd5fd322992af862ce5ab0 upstream. Put the child node np when it fails to get or register device. Fixes: e523f11141bd ("mtd: spi-nor: add hisilicon spi-nor flash controller driver") Cc: stable@vger.kernel.org Signed-off-by: Pan Bian <bianpan2016@163.com> [ta: Add Fixes tag and Cc stable] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20210121091847.85362-1-bianpan2016@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04mtd: spi-nor: core: Add erase size check for erase command initializationTakahiro Kuwano1-0/+1
commit 58fa22f68fcaff20ce4d08a6adffa64f65ccd37d upstream. Even if erase type is same as previous region, erase size can be different if the previous region is overlaid region. Since 'region->size' is assigned to 'cmd->size' for overlaid region, comparing 'erase->size' and 'cmd->size' can detect previous overlaid region. Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> [ta: Add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/13d47e8d8991b8a7fd8cc7b9e2a5319c56df35cc.1601612872.git.Takahiro.Kuwano@infineon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04mtd: spi-nor: core: Fix erase type discovery for overlaid regionTakahiro Kuwano1-4/+5
commit 969b276718de37dfe66fce3a5633f611e8cd58fd upstream. In case of overlaid regions in which their biggest erase size command overpasses in size the region's size, only the non-overlaid portion of the sector gets erased. For example, if a Sector Erase command is applied to a 256-kB range that is overlaid by 4-kB sectors, the overlaid 4-kB sectors are not affected by the erase. For overlaid regions, 'region->size' is assigned to 'cmd->size' later in spi_nor_init_erase_cmd(), so 'erase->size' can be greater than 'len'. Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> [ta: Update commit description, add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/fa5d8b944a5cca488ac54ba37c95e775ac2deb34.1601612872.git.Takahiro.Kuwano@infineon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04mtd: spi-nor: sfdp: Fix wrong erase type bitmask for overlaid regionTakahiro Kuwano1-1/+1
commit abdf5a5ef9652bad4d58058bc22ddf23543ba3e1 upstream. At the time spi_nor_region_check_overlay() is called, the erase types are sorted in ascending order of erase size. The 'erase_type' should be masked with 'BIT(erase[i].idx)' instead of 'BIT(i)'. Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> [ta: Add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/fd90c40d5b626a1319a78fc2bcee79a8871d4d57.1601612872.git.Takahiro.Kuwano@infineon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04mtd: spi-nor: sfdp: Fix last erase region markingTakahiro Kuwano1-2/+1
commit 9166f4af32db74e1544a2149aef231ff24515ea3 upstream. The place of spi_nor_region_mark_end() must be moved, because 'i' is re-used for the index of erase[]. Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> [ta: Add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/02ce8d84b7989ebee33382f6494df53778dd508e.1601612872.git.Takahiro.Kuwano@infineon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04spi: cadence-quadspi: Abort read if dummy cycles required are too manyPratyush Yadav1-1/+1
[ Upstream commit ceeda328edeeeeac7579e9dbf0610785a3b83d39 ] The controller can only support up to 31 dummy cycles. If the command requires more it falls back to using 31. This command is likely to fail because the correct number of cycles are not waited upon. Rather than silently issuing an incorrect command, fail loudly so the caller can get a chance to find out the command can't be supported by the controller. Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20201222184425.7028-3-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04mtd: parsers: afs: Fix freeing the part name memory in failureManivannan Sadhasivam1-3/+1
[ Upstream commit 7b844cf445f0a7daa68be0ce71eb2c88d68b0c5d ] In the case of failure while parsing the partitions, the iterator should be pre decremented by one before starting to free the memory allocated by kstrdup(). Because in the failure case, kstrdup() will not succeed and thus no memory will be allocated for the current iteration. Fixes: 1fca1f6abb38 ("mtd: afs: simplify partition parsing") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210104041137.113075-5-manivannan.sadhasivam@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04mtd: parser: imagetag: fix error codes in bcm963xx_parse_imagetag_partitions()Dan Carpenter1-0/+4
[ Upstream commit 12ba8f8ce29fdd277f3100052eddc1afd2f5ea3f ] If the kstrtouint() calls fail, then this should return a negative error code but it currently returns success. Fixes: dd84cb022b31 ("mtd: bcm63xxpart: move imagetag parsing to its own parser") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/YBKFtNaFHGYBj+u4@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-01-09Revert "mtd: spinand: Fix OOB read"Felix Fietkau1-4/+0
This reverts stable commit baad618d078c857f99cc286ea249e9629159901f. This commit is adding lines to spinand_write_to_cache_op, wheras the upstream commit 868cbe2a6dcee451bd8f87cbbb2a73cf463b57e5 that this was supposed to backport was touching spinand_read_from_cache_op. It causes a crash on writing OOB data by attempting to write to read-only kernel memory. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30mtd: rawnand: meson: fix meson_nfc_dma_buffer_release() argumentsSergei Antonov1-1/+1
commit c13d845e9a69580424d40b7b101c37d4f71bcd63 upstream. Arguments 'infolen' and 'datalen' to meson_nfc_dma_buffer_release() were mixed up. Fixes: 8fae856c53500 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Cc: stable@vger.kernel.org Signed-off-by: Sergei Antonov <saproj@gmail.com> Acked-by: Liang Yang <liang.yang@amlogic.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201028094940.11765-1-saproj@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30mtd: rawnand: qcom: Fix DMA sync on FLASH_STATUS register readPraveenkumar I1-0/+2
commit bc3686021122de953858a5be4cbf6e3f1d821e79 upstream. After each codeword NAND_FLASH_STATUS is read for possible operational failures. But there is no DMA sync for CPU operation before reading it and this leads to incorrect or older copy of DMA buffer in reg_read_buf. This patch adds the DMA sync on reg_read_buf for CPU before reading it. Fixes: 5bc36b2bf6e2 ("mtd: rawnand: qcom: check for operation errors in case of raw read") Cc: stable@vger.kernel.org Signed-off-by: Praveenkumar I <ipkumar@codeaurora.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1602230872-25616-1-git-send-email-ipkumar@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30mtd: parser: cmdline: Fix parsing of part-names with colonsSven Eckelmann1-1/+13
commit 639a82434f16a6df0ce0e7c8595976f1293940fd upstream. Some devices (especially QCA ones) are already using hardcoded partition names with colons in it. The OpenMesh A62 for example provides following mtd relevant information via cmdline: root=31:11 mtdparts=spi0.0:256k(0:SBL1),128k(0:MIBIB),384k(0:QSEE),64k(0:CDT),64k(0:DDRPARAMS),64k(0:APPSBLENV),512k(0:APPSBL),64k(0:ART),64k(custom),64k(0:KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive) rootfsname=rootfs rootwait The change to split only on the last colon between mtd-id and partitions will cause newpart to see following string for the first partition: KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive) Such a partition list cannot be parsed and thus the device fails to boot. Avoid this behavior by making sure that the start of the first part-name ("(") will also be the last byte the mtd-id split algorithm is using for its colon search. Fixes: eb13fa022741 ("mtd: parser: cmdline: Support MTD names containing one or more colons") Cc: stable@vger.kernel.org Cc: Ron Minnich <rminnich@google.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201124062506.185392-1-sven@narfation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30mtd: spinand: Fix OOB readMiquel Raynal1-0/+4
commit 868cbe2a6dcee451bd8f87cbbb2a73cf463b57e5 upstream. So far OOB have never been used in SPI-NAND, add the missing memcpy to make it work properly. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-6-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30mtd: rawnand: gpmi: Fix the random DMA timeout issueHan Xu1-9/+21
[ Upstream commit 7671edeb193910482a9b0c22cd32176e7de7b2ed ] To get better performance, current gpmi driver collected and chained all small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and wait for complete at the end. But some random DMA timeout found in this new driver, with the help of ftrace, we found the root cause is as follows: Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6 DMA transfers and the DMA chain triggered at the end. It waits for bch completion and check jiffies if it's timeout. The typical function graph shown below, 63.216351 | 1) | gpmi_ecc_read_page() { 63.216352 | 1) 0.750 us | gpmi_bch_layout_std(); 63.216354 | 1) | gpmi_nfc_exec_op() { 63.216355 | 1) | gpmi_chain_command() { 63.216356 | 1) | mxs_dma_prep_slave_sg() { 63.216357 | 1) | /* mxs chan ccw idx: 0 */ 63.216358 | 1) 1.750 us | } 63.216359 | 1) | mxs_dma_prep_slave_sg() { 63.216360 | 1) | /* mxs chan ccw idx: 1 */ 63.216361 | 1) 2.000 us | } 63.216361 | 1) 6.500 us | } 63.216362 | 1) | gpmi_chain_command() { 63.216363 | 1) | mxs_dma_prep_slave_sg() { 63.216364 | 1) | /* mxs chan ccw idx: 2 */ 63.216365 | 1) 1.750 us | } 63.216366 | 1) | mxs_dma_prep_slave_sg() { 63.216367 | 1) | /* mxs chan ccw idx: 3 */ 63.216367 | 1) 1.750 us | } 63.216368 | 1) 5.875 us | } 63.216369 | 1) | /* gpmi_chain_wait_ready */ 63.216370 | 1) | mxs_dma_prep_slave_sg() { 63.216372 | 1) | /* mxs chan ccw idx: 4 */ 63.216373 | 1) 3.000 us | } 63.216374 | 1) | /* gpmi_chain_data_read */ 63.216376 | 1) | mxs_dma_prep_slave_sg() { 63.216377 | 1) | /* mxs chan ccw idx: 5 */ 63.216378 | 1) 2.000 us | } 63.216379 | 1) 1.125 us | mxs_dma_tx_submit(); 63.216381 | 1) 1.000 us | mxs_dma_enable_chan(); 63.216712 | 0) 2.625 us | mxs_dma_int_handler(); 63.216717 | 0) 4.250 us | bch_irq(); 63.216723 | 0) 1.250 us | mxs_dma_tasklet(); 63.216723 | 1) | /* jiffies left 250 */ 63.216725 | 1) ! 372.000 us | } 63.216726 | 1) 2.625 us | gpmi_count_bitflips(); 63.216730 | 1) ! 379.125 us | } but it's not gurantee that bch irq handled always after dma irq handled, sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore, another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ handled, this messed up the next DMA chain and causes DMA timeout. Check the trace log when issue happened. 63.218923 | 1) | gpmi_ecc_read_page() { 63.218924 | 1) 0.625 us | gpmi_bch_layout_std(); 63.218926 | 1) | gpmi_nfc_exec_op() { 63.218927 | 1) | gpmi_chain_command() { 63.218928 | 1) | mxs_dma_prep_slave_sg() { 63.218929 | 1) | /* mxs chan ccw idx: 0 */ 63.218929 | 1) 1.625 us | } 63.218931 | 1) | mxs_dma_prep_slave_sg() { 63.218931 | 1) | /* mxs chan ccw idx: 1 */ 63.218932 | 1) 1.750 us | } 63.218933 | 1) 5.875 us | } 63.218934 | 1) | gpmi_chain_command() { 63.218934 | 1) | mxs_dma_prep_slave_sg() { 63.218935 | 1) | /* mxs chan ccw idx: 2 */ 63.218936 | 1) 1.875 us | } 63.218937 | 1) | mxs_dma_prep_slave_sg() { 63.218938 | 1) | /* mxs chan ccw idx: 3 */ 63.218939 | 1) 1.625 us | } 63.218939 | 1) 5.875 us | } 63.218940 | 1) | /* gpmi_chain_wait_ready */ 63.218941 | 1) | mxs_dma_prep_slave_sg() { 63.218942 | 1) | /* mxs chan ccw idx: 4 */ 63.218942 | 1) 1.625 us | } 63.218943 | 1) | /* gpmi_chain_data_read */ 63.218944 | 1) | mxs_dma_prep_slave_sg() { 63.218945 | 1) | /* mxs chan ccw idx: 5 */ 63.218947 | 1) 2.375 us | } 63.218948 | 1) 0.625 us | mxs_dma_tx_submit(); 63.218949 | 1) 1.000 us | mxs_dma_enable_chan(); 63.219276 | 0) 5.125 us | bch_irq(); <---- 63.219283 | 1) | /* jiffies left 250 */ 63.219285 | 1) ! 358.625 us | } 63.219286 | 1) 2.750 us | gpmi_count_bitflips(); 63.219289 | 1) ! 366.000 us | } 63.219290 | 1) | gpmi_ecc_read_page() { 63.219291 | 1) 0.750 us | gpmi_bch_layout_std(); 63.219293 | 1) | gpmi_nfc_exec_op() { 63.219294 | 1) | gpmi_chain_command() { 63.219295 | 1) | mxs_dma_prep_slave_sg() { 63.219295 | 0) 1.875 us | mxs_dma_int_handler(); <---- 63.219296 | 1) | /* mxs chan ccw idx: 6 */ 63.219297 | 1) 2.250 us | } 63.219298 | 1) | mxs_dma_prep_slave_sg() { 63.219298 | 0) 1.000 us | mxs_dma_tasklet(); 63.219299 | 1) | /* mxs chan ccw idx: 0 */ 63.219300 | 1) 1.625 us | } 63.219300 | 1) 6.375 us | } 63.219301 | 1) | gpmi_chain_command() { 63.219302 | 1) | mxs_dma_prep_slave_sg() { 63.219303 | 1) | /* mxs chan ccw idx: 1 */ 63.219304 | 1) 1.625 us | } 63.219305 | 1) | mxs_dma_prep_slave_sg() { 63.219306 | 1) | /* mxs chan ccw idx: 2 */ 63.219306 | 1) 1.875 us | } 63.219307 | 1) 6.000 us | } 63.219308 | 1) | /* gpmi_chain_wait_ready */ 63.219308 | 1) | mxs_dma_prep_slave_sg() { 63.219309 | 1) | /* mxs chan ccw idx: 3 */ 63.219310 | 1) 2.000 us | } 63.219311 | 1) | /* gpmi_chain_data_read */ 63.219312 | 1) | mxs_dma_prep_slave_sg() { 63.219313 | 1) | /* mxs chan ccw idx: 4 */ 63.219314 | 1) 1.750 us | } 63.219315 | 1) 0.625 us | mxs_dma_tx_submit(); 63.219316 | 1) 0.875 us | mxs_dma_enable_chan(); 64.224227 | 1) | /* jiffies left 0 */ In the first gpmi_nfc_exec_op, bch_irq comes first and gpmi_nfc_exec_op exits, but DMA IRQ still not happened yet until the middle of following gpmi_nfc_exec_op, the first DMA transfer index get messed and DMA get timeout. To fix the issue, when there is bch ops in DMA chain, the gpmi_nfc_exec_op should wait for both completions rather than bch completion only. Fixes: ef347c0cfd61 ("mtd: rawnand: gpmi: Implement exec_op") Signed-off-by: Han Xu <han.xu@nxp.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201209035104.22679-3-han.xu@nxp.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30mtd: rawnand: meson: Fix a resource leak in initDan Carpenter1-1/+4
[ Upstream commit ad8566d3555c4731e6b48823b92d3929b0394c14 ] Call clk_disable_unprepare(nfc->phase_rx) if the clk_set_rate() function fails to avoid a resource leak. Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/X8ikVCnUsfTpffFB@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30mtd: rawnand: gpmi: fix reference count leak in gpmi opsZhang Qilong1-2/+6
[ Upstream commit 1b391c7f2e863985668d705f525af3ceb55bc800 ] pm_runtime_get_sync() will increment pm usage at first and it will resume the device later. If runtime of the device has error or device is in inaccessible state(or other error state), resume operation will fail. If we do not call put operation to decrease the reference, it will result in reference leak in the two functions(gpmi_init and gpmi_nfc_exec_op). Moreover, this device cannot enter the idle state and always stay busy or other non-idle state later. So we fixed it through adding pm_runtime_put_noidle. Fixes: 5bc6bb603b4d0 ("mtd: rawnand: gpmi: Fix suspend/resume problem") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Acked-by: Han Xu <han.xu@nxp.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201107110552.1568742-1-zhangqilong3@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10mtd: spi-nor: Don't copy self-pointing struct aroundAlexander Sverdlin1-3/+2
commit 69a8eed58cc09aea3b01a64997031dd5d3c02c07 upstream. spi_nor_parse_sfdp() modifies the passed structure so that it points to itself (params.erase_map.regions to params.erase_map.uniform_region). This makes it impossible to copy the local struct anywhere else. Therefore only use memcpy() in backup-restore scenario. The bug may show up like below: BUG: unable to handle page fault for address: ffffc90000b377f8 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 3500 Comm: flashcp Tainted: G O 5.4.53-... #1 ... RIP: 0010:spi_nor_erase+0x8e/0x5c0 Code: 64 24 18 89 db 4d 8b b5 d0 04 00 00 4c 89 64 24 18 4c 89 64 24 20 eb 12 a8 10 0f 85 59 02 00 00 49 83 c6 10 0f 84 4f 02 00 00 <49> 8b 06 48 89 c2 48 83 e2 c0 48 89 d1 49 03 4e 08 48 39 cb 73 d8 RSP: 0018:ffffc9000217fc48 EFLAGS: 00010206 RAX: 0000000000740000 RBX: 0000000000000000 RCX: 0000000000740000 RDX: ffff8884550c9980 RSI: ffff88844f9c0bc0 RDI: ffff88844ede7bb8 RBP: 0000000000740000 R08: ffffffff815bfbe0 R09: ffff88844f9c0bc0 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000217fc60 R13: ffff88844ede7818 R14: ffffc90000b377f8 R15: 0000000000000000 FS: 00007f4699780500(0000) GS:ffff88846ff00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90000b377f8 CR3: 00000004538ee000 CR4: 0000000000340fe0 Call Trace: part_erase+0x27/0x50 mtdchar_ioctl+0x831/0xba0 ? filemap_map_pages+0x186/0x3d0 ? do_filp_open+0xad/0x110 ? _copy_to_user+0x22/0x30 ? cp_new_stat+0x150/0x180 mtdchar_unlocked_ioctl+0x2a/0x40 do_vfs_ioctl+0xa0/0x630 ? __do_sys_newfstat+0x3c/0x60 ksys_ioctl+0x70/0x80 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x6a/0x200 ? prepare_exit_to_usermode+0x50/0xd0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f46996b6817 Cc: stable@vger.kernel.org Fixes: c46872170a54 ("mtd: spi-nor: Move erase_map to 'struct spi_nor_flash_parameter'") Co-developed-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com> Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Tested-by: Baurzhan Ismagulov <ibr@radix50.net> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005084803.23460-1-alexander.sverdlin@nokia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05ubi: check kthread_should_stop() after the setting of task stateZhihao Cheng1-0/+13
commit d005f8c6588efcfbe88099b6edafc6f58c84a9c1 upstream. A detach hung is possible when a race occurs between the detach process and the ubi background thread. The following sequences outline the race: ubi thread: if (list_empty(&ubi->works)... ubi detach: set_bit(KTHREAD_SHOULD_STOP, &kthread->flags) => by kthread_stop() wake_up_process() => ubi thread is still running, so 0 is returned ubi thread: set_current_state(TASK_INTERRUPTIBLE) schedule() => ubi thread will never be scheduled again ubi detach: wait_for_completion() => hung task! To fix that, we need to check kthread_should_stop() after we set the task state, so the ubi thread will either see the stop bit and exit or the task state is reset to runnable such that it isn't scheduled out indefinitely. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Cc: <stable@vger.kernel.org> Fixes: 801c135ce73d5df1ca ("UBI: Unsorted Block Images") Reported-by: syzbot+853639d0cb16c31c7a14@syzkaller.appspotmail.com Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29mtd: spinand: gigadevice: Add QE BitHauke Mehrtens1-5/+5
[ Upstream commit aea7687e77bebce5b67fab9d03347bd8df7933c7 ] The following GigaDevice chips have the QE BIT in the feature flags, I checked the datasheets, but did not try this. * GD5F1GQ4xExxG * GD5F1GQ4xFxxG * GD5F1GQ4UAYIG * GD5F4GQ4UAYIG The Quad operations like 0xEB mention that the QE bit has to be set. Fixes: c93c613214ac ("mtd: spinand: add support for GigaDevice GD5FxGQ4xA") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Tested-by: Chuanhong Guo <gch981213@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200820165121.3192-3-hauke@hauke-m.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mtd: spinand: gigadevice: Only one dummy byte in QUADIOHauke Mehrtens1-2/+2
[ Upstream commit 6387ad9caf8f09747a8569e5876086b72ee9382c ] The datasheet only lists one dummy byte in the 0xEH operation for the following chips: * GD5F1GQ4xExxG * GD5F1GQ4xFxxG * GD5F1GQ4UAYIG * GD5F4GQ4UAYIG Fixes: c93c613214ac ("mtd: spinand: add support for GigaDevice GD5FxGQ4xA") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Tested-by: Chuanhong Guo <gch981213@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200820165121.3192-2-hauke@hauke-m.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mtd: rawnand: vf610: disable clk on error handling path in probeEvgeny Novikov1-2/+4
[ Upstream commit cb7dc3178a9862614b1e7567d77f4679f027a074 ] vf610_nfc_probe() does not invoke clk_disable_unprepare() on one error handling path. The patch fixes that. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 6f0ce4dfc5a3 ("mtd: rawnand: vf610: Avoid a potential NULL pointer dereference") Signed-off-by: Evgeny Novikov <novikov@ispras.ru> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200806072634.23528-1-novikov@ispras.ru Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mtd: mtdoops: Don't write panic data twiceMark Tomlinson1-5/+6
[ Upstream commit c1cf1d57d1492235309111ea6a900940213a9166 ] If calling mtdoops_write, don't also schedule work to be done later. Although this appears to not be causing an issue, possibly because the scheduled work will never get done, it is confusing. Fixes: 016c1291ce70 ("mtd: mtdoops: do not use mtd->panic_write directly") Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200903034217.23079-1-mark.tomlinson@alliedtelesis.co.nz Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mtd: lpddr: fix excessive stack usage with clangArnd Bergmann1-16/+19
[ Upstream commit 3e1b6469f8324bee5927b063e2aca30d3e56b907 ] Building lpddr2_nvm with clang can result in a giant stack usage in one function: drivers/mtd/lpddr/lpddr2_nvm.c:399:12: error: stack frame size of 1144 bytes in function 'lpddr2_nvm_probe' [-Werror,-Wframe-larger-than=] The problem is that clang decides to build a copy of the mtd_info structure on the stack and then do a memcpy() into the actual version. It shouldn't really do it that way, but it's not strictly a bug either. As a workaround, use a static const version of the structure to assign most of the members upfront and then only set the few members that require runtime knowledge at probe time. Fixes: 96ba9dd65788 ("mtd: lpddr: add driver for LPDDR2-NVM PCM memories") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200505140136.263461-1-arnd@arndb.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01ubi: fastmap: Free unused fastmap anchor peb during detachHou Tao1-2/+13
[ Upstream commit c16f39d14a7e0ec59881fbdb22ae494907534384 ] When CONFIG_MTD_UBI_FASTMAP is enabled, fm_anchor will be assigned a free PEB during ubi_wl_init() or ubi_update_fastmap(). However if fastmap is not used or disabled on the MTD device, ubi_wl_entry related with the PEB will not be freed during detach. So Fix it by freeing the unused fastmap anchor during detach. Fixes: f9c34bb52997 ("ubi: Fix producing anchor PEBs") Reported-by: syzbot+f317896aae32eb281a58@syzkaller.appspotmail.com Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01mtd: parser: cmdline: Support MTD names containing one or more colonsBoris Brezillon1-3/+20
[ Upstream commit eb13fa0227417e84aecc3bd9c029d376e33474d3 ] Looks like some drivers define MTD names with a colon in it, thus making mtdpart= parsing impossible. Let's fix the parser to gracefully handle that case: the last ':' in a partition definition sequence is considered instead of the first one. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Ron Minnich <rminnich@google.com> Tested-by: Ron Minnich <rminnich@google.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01mtd: rawnand: omap_elm: Fix runtime PM imbalance on errorDinghao Liu1-0/+1
[ Upstream commit 37f7212148cf1d796135cdf8d0c7fee13067674b ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200522104008.28340-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01mtd: rawnand: gpmi: Fix runtime PM imbalance on errorDinghao Liu1-1/+3
[ Upstream commit 550e68ea36a6671a96576c0531685ce6e6c0d19d ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200522095139.19653-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01ubi: Fix producing anchor PEBsSascha Hauer5-43/+41
[ Upstream commit f9c34bb529975fe9f85b870a80c53a83a3c5a182 ] When a new fastmap is about to be written UBI must make sure it has a free block for a fastmap anchor available. For this ubi_update_fastmap() calls ubi_ensure_anchor_pebs(). This stopped working with 2e8f08deabbc ("ubi: Fix races around ubi_refill_pools()"), with this commit the wear leveling code is blocked and can no longer produce free PEBs. UBI then more often than not falls back to write the new fastmap anchor to the same block it was already on which means the same erase block gets erased during each fastmap write and wears out quite fast. As the locking prevents us from producing the anchor PEB when we actually need it, this patch changes the strategy for creating the anchor PEB. We no longer create it on demand right before we want to write a fastmap, but instead we create an anchor PEB right after we have written a fastmap. This gives us enough time to produce a new anchor PEB before it is needed. To make sure we have an anchor PEB for the very first fastmap write we call ubi_ensure_anchor_pebs() during initialisation as well. Fixes: 2e8f08deabbc ("ubi: Fix races around ubi_refill_pools()") Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01mtd: cfi_cmdset_0002: don't free cfi->cfiq in error path of cfi_amdstd_setup()Hou Tao1-1/+0
[ Upstream commit 03976af89e3bd9489d542582a325892e6a8cacc0 ] Else there may be a double-free problem, because cfi->cfiq will be freed by mtd_do_chip_probe() if both the two invocations of check_cmd_set() return failure. Signed-off-by: Hou Tao <houtao1@huawei.com> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21mtd: rawnand: fsl_upm: Remove unused mtd varBoris Brezillon1-1/+0
[ Upstream commit ccc49eff77bee2885447a032948959a134029fe3 ] The mtd var in fun_wait_rnb() is now unused, let's get rid of it and fix the warning resulting from this unused var. Fixes: 50a487e7719c ("mtd: rawnand: Pass a nand_chip object to chip->dev_ready()") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200603134922.1352340-2-boris.brezillon@collabora.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-19mtd: rawnand: qcom: avoid write to unavailable registerSivaprakash Murugesan1-1/+6
commit 443440cc4a901af462239d286cd10721aa1c7dfc upstream. SFLASHC_BURST_CFG is only available on older ipq NAND platforms, this register has been removed when the NAND controller got implemented in the qpic controller. Avoid writing this register on devices which are based on qpic NAND controller. Fixes: dce84760b09f ("mtd: nand: qcom: Support for IPQ8074 QPIC NAND controller") Cc: stable@vger.kernel.org Signed-off-by: Sivaprakash Murugesan <sivaprak@codeaurora.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1591948696-16015-2-git-send-email-sivaprak@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-11mtd: properly check all write ioctls for permissionsGreg Kroah-Hartman1-9/+47
commit f7e6b19bc76471ba03725fe58e0c218a3d6266c3 upstream. When doing a "write" ioctl call, properly check that we have permissions to do so before copying anything from userspace or anything else so we can "fail fast". This includes also covering the MEMWRITE ioctl which previously missed checking for this. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [rw: Fixed locking issue] Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22mtd: rawnand: oxnas: Release all devices in the _remove() pathMiquel Raynal1-2/+6
commit 0a5f45e57e35d0840bedb816974ce2e63406cd8b upstream. oxnans_nand_remove() should release all MTD devices and clean all NAND devices, not only the first one registered. Fixes: 668592492409 ("mtd: nand: Add OX820 NAND Support") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-39-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22mtd: rawnand: oxnas: Unregister all devices on errorMiquel Raynal1-0/+8
commit b60391eb17b2956ff2fc4c348e5a464da21ff9cb upstream. On error, the oxnas probe path just frees the device which failed and aborts the probe, leaving unreleased resources. Fix this situation by calling mtd_device_unregister()/nand_cleanup() on these. Fixes: 668592492409 ("mtd: nand: Add OX820 NAND Support") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-38-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22mtd: rawnand: oxnas: Keep track of registered devicesMiquel Raynal1-4/+4
commit 383fc3f613e7eac9f2e3c13b6f9fb8c1f39cb9d5 upstream. All initialized and registered devices should be listed somewhere so that we can unregister/free them in the _remove() path. This patch is not a fix per-se but is needed to apply three other fixes coming right after, explaining the Fixes/Cc: stable tags. Fixes: 668592492409 ("mtd: nand: Add OX820 NAND Support") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-36-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22mtd: rawnand: brcmnand: fix CS0 layoutÁlvaro Fernández Rojas1-2/+3
commit 3d3fb3c5be9ce07fa85d8f67fb3922e4613b955b upstream. Only v3.3-v5.0 have a different CS0 layout. Controllers before v3.3 use the same layout for every CS. Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200522121524.4161539-3-noltari@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22mtd: rawnand: brcmnand: correctly verify erased pagesÁlvaro Fernández Rojas1-8/+11
commit dcb351c03f2fa6a599de1061b174167e03ee312b upstream. The current code checks that the whole OOB area is erased. This is a problem when JFFS2 cleanmarkers are added to the OOB, since it will fail due to the usable OOB bytes not being 0xff. Correct this by only checking that data and ECC bytes aren't 0xff. Fixes: 02b88eea9f9c ("mtd: brcmnand: Add check for erased page bitflips") Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200512082451.771212-1-noltari@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22mtd: rawnand: timings: Fix default tR_max and tCCS_min timingsMiquel Raynal1-3/+2
commit 4d8ec041d9c454029f6cd90622f6d81eb61e781c upstream. tR and tCCS are currently wrongly expressed in femtoseconds, while we expect these values to be expressed in picoseconds. Set right hardcoded values. Fixes: 6a943386ee36 mtd: rawnand: add default values for dynamic timings Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-3-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22mtd: rawnand: marvell: Fix probe error pathMiquel Raynal1-9/+14
commit c525b7af96714f72e316c70781570a4a3e1c2856 upstream. Ensure all chips are deregistered and cleaned in case of error during the probe. Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-5-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22mtd: rawnand: marvell: Use nand_cleanup() when the device is not yet registeredMiquel Raynal1-1/+1
commit 7a0c18fb5c71c6ac7d4662a145e4227dcd4a36a3 upstream. Do not call nand_release() while the MTD device has not been registered, use nand_cleanup() instead. Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-4-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22mtd: rawnand: marvell: Fix the condition on a return codeMiquel Raynal1-1/+1
commit c27075772d1f1c8aaf276db9943b35adda8a8b65 upstream. In a previous fix, I changed the condition on which the timeout of an IRQ is reached from: if (!ret) into: if (ret && !pending) While having a non-zero return code is usual in the Linux kernel, here ret comes from a wait_for_completion_timeout() which returns 0 when the waiting period is too long. Hence, the revised condition should be: if (!ret && !pending) The faulty patch did not produce any error because of the !pending condition so this change is finally purely cosmetic and does not change the actual driver behavior. Fixes: cafb56dd741e ("mtd: rawnand: marvell: prevent timeouts on a loaded machine") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-2-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22mtd: rawnand: tmio: Fix the probe error pathMiquel Raynal1-1/+1
commit 75e9a330a9bd48f97a55a08000236084fe3dae56 upstream. nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-57-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22mtd: rawnand: mtk: Fix the probe error pathMiquel Raynal1-1/+1
commit 8a82bbcadec877f5f938c54026278dfc1f05a332 upstream. nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-28-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22mtd: rawnand: pasemi: Fix the probe error pathMiquel Raynal1-1/+3
commit f51466901c07e6930435d30b02a21f0841174f61 upstream. nand_cleanup() is supposed to be called on error after a successful call to nand_scan() to free all NAND resources. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible, hence pointing it as the commit to fix for backporting purposes, even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-41-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22mtd: rawnand: plat_nand: Fix the probe error pathMiquel Raynal1-1/+1
commit 5284024b4dac5e94f7f374ca905c7580dbc455e9 upstream. nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible, hence pointing it as the commit to fix for backporting purposes, even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-43-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22mtd: rawnand: sunxi: Fix the probe error pathMiquel Raynal1-1/+1
commit 3d84515ffd8fb657e10fa5b1215e9f095fa7efca upstream. nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-54-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22mtd: rawnand: oxnas: Fix the probe error pathMiquel Raynal1-4/+4
commit 154298e2a3f6c9ce1d76cdb48d89fd5b107ea1a3 upstream. nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. While at it, be consistent and move the function call in the error path thanks to a goto statement. Fixes: 668592492409 ("mtd: nand: Add OX820 NAND Support") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-37-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22mtd: rawnand: socrates: Fix the probe error pathMiquel Raynal1-1/+1
commit 9c6c2e5cc77119ce0dacb4f9feedb73ce0354421 upstream. nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-51-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22mtd: rawnand: orion: Fix the probe error pathMiquel Raynal1-1/+1
commit be238fbf78e4c7c586dac235ab967d3e565a4d1a upstream. nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-34-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22mtd: rawnand: xway: Fix the probe error pathMiquel Raynal1-1/+1
commit 34531be5e804a8e1abf314a6c3a19fe342e4a154 upstream. nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-61-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-22 22:33:05 +0300