user/sven/linux.git/drivers/mtd, branch v6.1.99

mtd: rawnand: rockchip: ensure NVDDR timings are rejected

2024-07-11T10:47:15Z

commit b27d8946b5edd9827ee3c2f9ea1dd30022fb1ebe upstream. .setup_interface first gets called with a "target" value of NAND_DATA_IFACE_CHECK_ONLY, in which case an error is expected if the controller driver does not support the timing mode (NVDDR). Fixes: a9ecc8c814e9 ("mtd: rawnand: Choose the best timings, NV-DDR included") Signed-off-by: Val Packett Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240519031409.26464-1-val@packett.cool Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: Bypass a couple of sanity checks during NAND identification

2024-07-11T10:47:15Z

commit 8754d9835683e8fab9a8305acdb38a3aeb9d20bd upstream. Early during NAND identification, mtd_info fields have not yet been initialized (namely, writesize and oobsize) and thus cannot be used for sanity checks yet. Of course if there is a misuse of nand_change_read_column_op() so early we won't be warned, but there is anyway no actual check to perform at this stage as we do not yet know the NAND geometry. So, if the fields are empty, especially mtd->writesize which is *always* set quite rapidly after identification, let's skip the sanity checks. nand_change_read_column_op() is subject to be used early for ONFI/JEDEC identification in the very unlikely case of: - bitflips appearing in the parameter page, - the controller driver not supporting simple DATA_IN cycles. As nand_change_read_column_op() uses nand_fill_column_cycles() the logic explaind above also applies in this secondary helper. Fixes: c27842e7e11f ("mtd: rawnand: onfi: Adapt the parameter page read to constraint controllers") Fixes: daca31765e8b ("mtd: rawnand: jedec: Adapt the parameter page read to constraint controllers") Cc: stable@vger.kernel.org Reported-by: Alexander Dahl Closes: https://lore.kernel.org/linux-mtd/20240306-shaky-bunion-d28b65ea97d7@thorsis.com/ Reported-by: Steven Seeger Closes: https://lore.kernel.org/linux-mtd/DM6PR05MB4506554457CF95191A670BDEF7062@DM6PR05MB4506.namprd05.prod.outlook.com/ Signed-off-by: Miquel Raynal Tested-by: Sascha Hauer Link: https://lore.kernel.org/linux-mtd/20240516131320.579822-3-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: Ensure ECC configuration is propagated to upper layers

2024-07-11T10:47:15Z

commit 3a1b777eb9fb75d09c45ae5dd1d007eddcbebf1f upstream. Until recently the "upper layer" was MTD. But following incremental reworks to bring spi-nand support and more recently generic ECC support, there is now an intermediate "generic NAND" layer that also needs to get access to some values. When using "converted" ECC engines, like the software ones, these values are already propagated correctly. But otherwise when using good old raw NAND controller drivers, we need to manually set these values ourselves at the end of the "scan" operation, once these values have been negotiated. Without this propagation, later (generic) checks like the one warning users that the ECC strength is not high enough might simply no longer work. Fixes: 8c126720fe10 ("mtd: rawnand: Use the ECC framework nand_ecc_is_strong_enough() helper") Cc: stable@vger.kernel.org Reported-by: Sascha Hauer Closes: https://lore.kernel.org/all/Zhe2JtvvN1M4Ompw@pengutronix.de/ Signed-off-by: Miquel Raynal Tested-by: Sascha Hauer Link: https://lore.kernel.org/linux-mtd/20240507085842.108844-1-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman

mtd: partitions: redboot: Added conversion of operands to a larger type

2024-07-05T07:31:48Z

[ Upstream commit 1162bc2f8f5de7da23d18aa4b7fbd4e93c369c50 ] The value of an arithmetic expression directory * master->erasesize is subject to overflow due to a failure to cast operands to a larger data type before perfroming arithmetic Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Denis Arefev Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240315093758.20790-1-arefev@swemel.ru Signed-off-by: Sasha Levin

mtd: rawnand: hynix: fixed typo

2024-06-12T09:03:22Z

[ Upstream commit 6819db94e1cd3ce24a432f3616cd563ed0c4eaba ] The function hynix_nand_rr_init() should probably return an error code. Judging by the usage, it seems that the return code is passed up the call stack. Right now, it always returns 0 and the function hynix_nand_cleanup() in hynix_nand_init() has never been called. Found by RASU JSC and Linux Verification Center (linuxtesting.org) Fixes: 626994e07480 ("mtd: nand: hynix: Add read-retry support for 1x nm MLC NANDs") Signed-off-by: Maxim Korotkov Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240313102721.1991299-1-korotkov.maxim.s@gmail.com Signed-off-by: Sasha Levin

mtd: core: Report error if first mtd_otp_size() call fails in mtd_otp_nvmem_add()

2024-06-12T09:03:22Z

[ Upstream commit d44f0bbbd8d182debcce88bda55b05269f3d33d6 ] Jump to the error reporting code in mtd_otp_nvmem_add() if the mtd_otp_size() call fails. Without this fix, the error is not logged. Signed-off-by: Aapo Vienamo Reviewed-by: Mika Westerberg Reviewed-by: Michael Walle Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240313173425.1325790-2-aapo.vienamo@linux.intel.com Signed-off-by: Sasha Levin

mtd: diskonchip: work around ubsan link failure

2024-05-02T14:29:30Z

commit 21c9fb611c25d5cd038f6fe485232e7884bb0b3d upstream. I ran into a randconfig build failure with UBSAN using gcc-13.2: arm-linux-gnueabi-ld: error: unplaced orphan section `.bss..Lubsan_data31' from `drivers/mtd/nand/raw/diskonchip.o' I'm not entirely sure what is going on here, but I suspect this has something to do with the check for the end of the doc_locations[] array that contains an (unsigned long)0xffffffff element, which is compared against the signed (int)0xffffffff. If this is the case, we should get a runtime check for undefined behavior, but we instead get an unexpected build-time error. I would have expected this to work fine on 32-bit architectures despite the signed integer overflow, though on 64-bit architectures this likely won't ever work. Changing the contition to instead check for the size of the array makes the code safe everywhere and avoids the ubsan check that leads to the link error. The loop code goes back to before 2.6.12. Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240405143015.717429-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: meson: fix scrambling mode value in command macro

2024-04-03T13:19:27Z

[ Upstream commit ef6f463599e16924cdd02ce5056ab52879dc008c ] Scrambling mode is enabled by value (1 << 19). NFC_CMD_SCRAMBLER_ENABLE is already (1 << 19), so there is no need to shift it again in CMDRWGEN macro. Signed-off-by: Arseniy Krasnov Cc: Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240210214551.441610-1-avkrasnov@salutedevices.com Signed-off-by: Sasha Levin

ubi: correct the calculation of fastmap size

2024-04-03T13:19:27Z

[ Upstream commit 7f174ae4f39e8475adcc09d26c5a43394689ad6c ] Now that the calculation of fastmap size in ubi_calc_fm_size() is incorrect since it miss each user volume's ubi_fm_eba structure and the Internal UBI volume info. Let's correct the calculation. Cc: stable@vger.kernel.org Signed-off-by: Zhang Yi Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

ubi: Check for too small LEB size in VTBL code

2024-04-03T13:19:27Z

[ Upstream commit 68a24aba7c593eafa8fd00f2f76407b9b32b47a9 ] If the LEB size is smaller than a volume table record we cannot have volumes. In this case abort attaching. Cc: Chenyuan Yang Cc: stable@vger.kernel.org Fixes: 801c135ce73d ("UBI: Unsorted Block Images") Reported-by: Chenyuan Yang Closes: https://lore.kernel.org/linux-mtd/1433EB7A-FC89-47D6-8F47-23BE41B263B3@illinois.edu/ Signed-off-by: Richard Weinberger Reviewed-by: Zhihao Cheng Signed-off-by: Sasha Levin