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

mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information

2024-12-09T09:41:05Z

commit fee9b240916df82a8b07aef0fdfe96785417a164 upstream. These four chips: * W25N512GW * W25N01GW * W25N01JW * W25N02JW all require a single bit of ECC strength and thus feature an on-die Hamming-like ECC engine. There is no point in filling a ->get_status() callback for them because the main ECC status bytes are located in standard places, and retrieving the number of bitflips in case of corrected chunk is both useless and unsupported (if there are bitflips, then there is 1 at most, so no need to query the chip for that). Without this change, a kernel warning triggers every time a bit flips. Fixes: 6a804fb72de5 ("mtd: spinand: winbond: add support for serial NAND flash") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Frieder Schrempf Link: https://lore.kernel.org/linux-mtd/20241009125002.191109-3-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman

mtd: spinand: winbond: Fix 512GW and 02JW OOB layout

2024-12-09T09:41:05Z

commit c1247de51cab53fc357a73804c11fb4fba55b2d9 upstream. Both W25N512GW and W25N02JW chips have 64 bytes of OOB and thus cannot use the layout for 128 bytes OOB. Reference the correct layout instead. Fixes: 6a804fb72de5 ("mtd: spinand: winbond: add support for serial NAND flash") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Frieder Schrempf Link: https://lore.kernel.org/linux-mtd/20241009125002.191109-2-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman

ubi: fastmap: Fix duplicate slab cache names while attaching

2024-12-05T13:03:04Z

[ Upstream commit bcddf52b7a17adcebc768d26f4e27cf79adb424c ] Since commit 4c39529663b9 ("slab: Warn on duplicate cache names when DEBUG_VM=y"), the duplicate slab cache names can be detected and a kernel WARNING is thrown out. In UBI fast attaching process, alloc_ai() could be invoked twice with the same slab cache name 'ubi_aeb_slab_cache', which will trigger following warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0 The problem could be easily reproduced by loading UBI device by fastmap with CONFIG_DEBUG_VM=y. Fix it by using different slab names for alloc_ai() callers. Fixes: d2158f69a7d4 ("UBI: Remove alloc_ai() slab name from parameter list") Fixes: fdf10ed710c0 ("ubi: Rework Fastmap attach base code") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty

2024-12-05T13:03:04Z

[ Upstream commit c4595fe394a289927077e3da561db27811919ee0 ] Since commit 14072ee33d5a ("ubi: fastmap: Check wl_pool for free peb before wear leveling"), wear_leveling_worker() won't schedule fm_work if wear-leveling pool is empty, which could temporarily disable the wear-leveling until the fastmap is updated(eg. pool becomes empty). Fix it by scheduling fm_work if wl_pool is empty during wear-leveing. Fixes: 14072ee33d5a ("ubi: fastmap: Check wl_pool for free peb before wear leveling") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()

2024-12-05T13:02:54Z

commit 07593293ffabba14125c8998525adde5a832bfa3 upstream. The 'fw_vols' fwnode_handle initialized via device_get_named_child_node() requires explicit calls to fwnode_handle_put() when the variable is no longer required. Add the missing calls to fwnode_handle_put() before the function returns. Cc: stable@vger.kernel.org Fixes: 51932f9fc487 ("mtd: ubi: populate ubi volume fwnode") Signed-off-by: Javier Carrasco Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

ubi: wl: Put source PEB into correct list if trying locking LEB failed

2024-12-05T13:02:53Z

commit d610020f030bec819f42de327c2bd5437d2766b3 upstream. During wear-leveing work, the source PEB will be moved into scrub list when source LEB cannot be locked in ubi_eba_copy_leb(), which is wrong for non-scrub type source PEB. The problem could bring extra and ineffective wear-leveing jobs, which makes more or less negative effects for the life time of flash. Specifically, the process is divided 2 steps: 1. wear_leveling_worker // generate false scrub type PEB ubi_eba_copy_leb // MOVE_RETRY is returned leb_write_trylock // trylock failed scrubbing = 1; e1 is put into ubi->scrub 2. wear_leveling_worker // schedule false scrub type PEB for wl scrubbing = 1 e1 = rb_entry(rb_first(&ubi->scrub)) The problem can be reproduced easily by running fsstress on a small UBIFS partition(<64M, simulated by nandsim) for 5~10mins (CONFIG_MTD_UBI_FASTMAP=y,CONFIG_MTD_UBI_WL_THRESHOLD=50). Following message is shown: ubi0: scrubbed PEB 66 (LEB 0:10), data moved to PEB 165 Since scrub type source PEB has set variable scrubbing as '1', and variable scrubbing is checked before variable keep, so the problem can be fixed by setting keep variable as 1 directly if the source LEB cannot be locked. Fixes: e801e128b220 ("UBI: fix missing scrub when there is a bit-flip") CC: stable@vger.kernel.org Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: core: replace dummy buswidth from addr to data

2024-12-05T13:02:51Z

commit 98d1fb94ce75f39febd456d6d3cbbe58b6678795 upstream. The default dummy cycle for Macronix SPI NOR flash in Octal Output Read Mode(1-1-8) is 20. Currently, the dummy buswidth is set according to the address bus width. In the 1-1-8 mode, this means the dummy buswidth is 1. When converting dummy cycles to bytes, this results in 20 x 1 / 8 = 2 bytes, causing the host to read data 4 cycles too early. Since the protocol data buswidth is always greater than or equal to the address buswidth. Setting the dummy buswidth to match the data buswidth increases the likelihood that the dummy cycle-to-byte conversion will be divisible, preventing the host from reading data prematurely. Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Cc: stable@vger.kernel.org Reviewed-by: Pratyush Yadav Signed-off-by: Cheng Ming Lin Link: https://lore.kernel.org/r/20241112075242.174010-2-linchengming884@gmail.com Signed-off-by: Tudor Ambarus Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in RD_ANY_REG_OP

2024-12-05T13:02:05Z

[ Upstream commit b61c35e3404557779ec427c077f7a9f057bb053d ] In octal DTR mode, RD_ANY_REG_OP needs to use 4-byte address regardless of flash's internal address mode. Use nor->addr_nbytes which is set to 4 during setup. Fixes: eff9604390d6 ("mtd: spi-nor: spansion: add octal DTR support in RD_ANY_REG_OP") Signed-off-by: Takahiro Kuwano Link: https://lore.kernel.org/r/20241016000837.17951-1-Takahiro.Kuwano@infineon.com Signed-off-by: Tudor Ambarus Signed-off-by: Sasha Levin

mtd: rawnand: atmel: Fix possible memory leak

2024-12-05T13:02:05Z

[ Upstream commit 6d734f1bfc336aaea91313a5632f2f197608fadd ] The pmecc "user" structure is allocated in atmel_pmecc_create_user() and was supposed to be freed with atmel_pmecc_destroy_user(), but this other helper is never called. One solution would be to find the proper location to call the destructor, but the trend today is to switch to device managed allocations, which in this case fits pretty well. Replace kzalloc() by devm_kzalloc() and drop the destructor entirely. Reported-by: "Dr. David Alan Gilbert" Closes: https://lore.kernel.org/all/ZvmIvRJCf6VhHvpo@gallifrey/ Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20241001203149.387655-1-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin

mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE

2024-12-05T13:02:04Z

[ Upstream commit 7d189579a287d5c568db623c5fc2344cce98a887 ] The rpc-if-hyperflash driver can be compiled as a module, but lacks MODULE_DEVICE_TABLE() and will therefore not be loaded automatically. Fix this. Fixes: 5de15b610f78 ("mtd: hyperbus: add Renesas RPC-IF driver") Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Reviewed-by: Vignesh Raghavendra Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240731080846.257139-1-biju.das.jz@bp.renesas.com Signed-off-by: Sasha Levin