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

mtd: rawnand: rockchip: ensure NVDDR timings are rejected

2024-07-11T10:49:18Z

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:49:18Z

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: Fix the nand_read_data_op() early check

2024-07-11T10:49:17Z

commit 5da39530d19946f6241de84d1db69da2f5c61da7 upstream. The nand_read_data_op() operation, which only consists in DATA_IN cycles, is sadly not supported by all controllers despite being very basic. The core, for some time, supposed all drivers would support it. An improvement to this situation for supporting more constrained controller added a check to verify if the operation was supported before attempting it by running the function with the check_only boolean set first, and then possibly falling back to another (possibly slightly less optimized) alternative. An even newer addition moved that check very early and probe time, in order to perform the check only once. The content of the operation was not so important, as long as the controller driver would tell whether such operation on the NAND bus would be possible or not. In practice, no buffer was provided (no fake buffer or whatever) as it is anyway not relevant for the "check_only" condition. Unfortunately, early in the function, there is an if statement verifying that the input parameters are right for normal use, making the early check always unsuccessful. Fixes: 9f820fc0651c ("mtd: rawnand: Check the data only read pattern only once") 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 Reviewed-by: Alexander Dahl Link: https://lore.kernel.org/linux-mtd/20240516131320.579822-2-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman

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

2024-07-11T10:49:17Z

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:33:51Z

[ 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:11:58Z

[ 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:11:58Z

[ 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: limit OTP NVMEM cell parse to non-NAND devices

2024-05-17T10:01:55Z

[ Upstream commit d2d73a6dd17365c43e109263841f7c26da55cfb0 ] MTD OTP logic is very fragile on parsing NVMEM cell and can be problematic with some specific kind of devices. The problem was discovered by e87161321a40 ("mtd: rawnand: macronix: OTP access for MX30LFxG18AC") where OTP support was added to a NAND device. With the case of NAND devices, it does require a node where ECC info are declared and all the fixed partitions, and this cause the OTP codepath to parse this node as OTP NVMEM cells, making probe fail and the NAND device registration fail. MTD OTP parsing should have been limited to always using compatible to prevent this error by using node with compatible "otp-user" or "otp-factory". NVMEM across the years had various iteration on how cells could be declared in DT, in some old implementation, no_of_node should have been enabled but now add_legacy_fixed_of_cells should be used to disable NVMEM to parse child node as NVMEM cell. To fix this and limit any regression with other MTD that makes use of declaring OTP as direct child of the dev node, disable add_legacy_fixed_of_cells if we detect the MTD type is Nand. With the following logic, the OTP NVMEM entry is correctly created with no cells and the MTD Nand is correctly probed and partitions are correctly exposed. Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support") Cc: # v6.7+ Signed-off-by: Christian Marangi Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240412105030.1598-1-ansuelsmth@gmail.com Signed-off-by: Sasha Levin

nvmem: add explicit config option to read old syntax fixed OF cells

2024-05-17T10:01:55Z

[ Upstream commit 2cc3b37f5b6df8189d55d0e812d9658ce256dfec ] Binding for fixed NVMEM cells defined directly as NVMEM device subnodes has been deprecated. It has been replaced by the "fixed-layout" NVMEM layout binding. New syntax is meant to be clearer and should help avoiding imprecise bindings. NVMEM subsystem already supports the new binding. It should be a good idea to limit support for old syntax to existing drivers that actually support & use it (we can't break backward compatibility!). That way we additionally encourage new bindings & drivers to ignore deprecated binding. It wasn't clear (to me) if rtc and w1 code actually uses old syntax fixed cells. I enabled them to don't risk any breakage. Signed-off-by: Rafał Miłecki [for meson-{efuse,mx-efuse}.c] Acked-by: Martin Blumenstingl [for mtk-efuse.c, nvmem/core.c, nvmem-provider.h] Reviewed-by: AngeloGioacchino Del Regno [MT8192, MT8195 Chromebooks] Tested-by: AngeloGioacchino Del Regno [for microchip-otpc.c] Reviewed-by: Claudiu Beznea [SAMA7G5-EK] Tested-by: Claudiu Beznea Acked-by: Jernej Skrabec Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20231020105545.216052-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: d2d73a6dd173 ("mtd: limit OTP NVMEM cell parse to non-NAND devices") Signed-off-by: Sasha Levin

mtd: diskonchip: work around ubsan link failure

2024-05-02T14:32:46Z

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