kernel/git/stable/linux-stable.git/drivers/mtd, branch linux-rolling-lts

mtd: rawnand: pl353: Fix debug prints

2026-09-14T11:36:16+00:00

[ Upstream commit 2b7baaddf1bc3e39206a0354449fdc349945b86b ] They are partially incorrect since "software" engine does not mean hamming, the "none" cae is also falling into this print, and on-die means there is some kind of hardware support; we prefer to use the wording on-host vs. on-die. Fix all those prints. Fixes: 1e06dbfdfb85 ("mtd: rawnand: pl353: Add message about ECC mode") Signed-off-by: Miquel Raynal (DAVE) Acked-by: Michal Simek Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin

UBI: fix two issues in the ubi.mtd MODULE_PARM_DESC

2026-09-14T11:35:53+00:00

[ Upstream commit ff7937d14f5333ec7e6fb50d00a152d7974f4105 ] Fix two issues introduced before: - The parameter format string was missing the enable_fm and need_resv_pool tokens introduced in an earlier commit. - The bad-block reservation note was misplaced after Example 5 instead of after Example 3. It was misplaced due to an earlier patch. Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line") Signed-off-by: Ran Hongyun Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

mtd: ubi: Release device reference on busy detach

2026-09-14T11:35:53+00:00

[ Upstream commit 31dd710cd84d5dd63c49f640d3a9f36c9699ca95 ] ubi_detach_mtd_dev() obtains a device reference through ubi_get_device() before checking whether the UBI device is busy. The busy return path drops ubi->ref_count but leaves the device reference held, so the device object cannot be released after a later detach. Drop the device reference before returning -EBUSY. Fixes: 7e84c961b2eb ("mtd: ubi: introduce pre-removal notification for UBI volumes") Signed-off-by: Yuho Choi Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

ubi: Fix rollback for explicit UBI device numbers

2026-09-14T11:35:53+00:00

[ Upstream commit 5b0a6b554e12a97f9771a9a9f4ea1f5457373c73 ] ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored. Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line") Signed-off-by: Yuho Choi Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBs

2026-09-14T11:35:53+00:00

[ Upstream commit be04fce9945aac2a843f5d16725391eb80d948ef ] In ubi_update_fastmap(), when no fresh PEB is available to replace an old fastmap PEB, the old PEB is reused by erasing it synchronously via ubi_sync_erase() with the torture flag hardcoded to zero. However, old_fm->to_be_tortured[] may be non-zero: it is set during fastmap scanning when ubi_io_read_data()/ubi_io_read_ec_hdr() reports UBI_IO_BITFLIPS, meaning the PEB showed signs of bit decay and should be tortured to verify it is still reliable. When the old PEB is instead returned to the WL sub-system via ubi_wl_put_fm_peb(), the to_be_tortured flag is honored. The synchronous reuse path is inconsistent: it silently skips the torture test for PEBs that exhibited bit-flips. Fix it by passing &old_fm->to_be_tortured[i] to ubi_sync_erase(). Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

UBI: Preserve torture flag when rescheduling failed erasures

2026-09-14T11:35:53+00:00

[ Upstream commit 420477a84f1e52babfe60a43dbdd0988ed956845 ] In __erase_worker(), when ubi_sync_erase() returns -EINTR, -ENOMEM, -EAGAIN, or -EBUSY, the physical eraseblock is rescheduled for erasure via schedule_erase() with the torture flag hardcoded to 0. This unconditionally drops the torture request. If the error occurred before torture_peb() completed (e.g., -ENOMEM from the ec_hdr allocation in ubi_sync_erase(), errors from self_check_not_bad()/nor_erase_prepare() in ubi_io_sync_erase(), or torture_peb() failing mid-test because its internal do_sync_erase()/ ubi_io_read()/ubi_io_write() returned one of the above error codes), the torture test was never finished. Such a PEB may reach the free pool without being tortured, defeating the purpose of the torture test for detecting marginally-bad eraseblocks. If the error occurred after torture_peb() succeeded (the final do_sync_erase() in ubi_io_sync_erase() or ubi_io_write_ec_hdr() in ubi_sync_erase() failed), the torture has already been done and need not be repeated. Pass the torture flag by pointer to ubi_sync_erase() and ubi_io_sync_erase(), and clear it to zero once torture_peb() has completed successfully. __erase_worker() then forwards the updated wl_wrk->torture to schedule_erase(): torture already done is dropped, torture not completed is preserved across the reschedule. Fixes: 784c145444e7 ("UBI: fix error handling in erase worker") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition()

2026-09-14T11:34:47+00:00

[ Upstream commit b759d5bb6265419344ee9729fd0dc07ad85719d8 ] mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a ("mtd: prepare partition add and del functions for ioctl requests") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && !(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the "out of reach" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK. Fixes: 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") Signed-off-by: zhouminqiang Reviewed-by: Zhihao Cheng Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin

mtd: mtdswap: Avoid freeing registered blktrans device twice

2026-09-14T11:34:47+00:00

[ Upstream commit 779aa4c66a96bf43d2d62982ea1a9096a9128d87 ] In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries") Signed-off-by: Ruoyu Wang Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin

mtd: intel-dg: Fix runtime PM error path in probe

2026-09-14T11:34:47+00:00

[ Upstream commit df6f582df3377af316a60ca8ee0d590b2d03924d ] intel_dg_mtd_probe() allocates region names before enabling runtime PM and before calling pm_runtime_resume_and_get(). If kasprintf() fails while building a region name, the error path jumps to err, which calls pm_runtime_put(). At that point there has not been a successful pm_runtime_resume_and_get() call to balance, so the runtime PM usage count can underflow. Jump to err_norpm from the kasprintf() failure path, as the runtime PM reference has not been acquired yet. Fixes: 779c59274d03 ("mtd: intel-dg: Fix accessing regions before setting nregions") Signed-off-by: Guangshuo Li Reviewed-by: Raag Jadav Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin

mtd: intel-dg: wake card on operations

2026-09-14T11:34:47+00:00

[ Upstream commit 3e9c49d4c3063dcf7ddcdea4c5e3aa21eae359d0 ] The Intel DG cards do not have separate power control for persistent memory. The memory is available when the whole card is awake. Enable runtime PM in mtd driver to notify parent graphics driver that whole card should be kept awake while nvm operations are performed through this driver. Signed-off-by: Alexander Usyskin Signed-off-by: Miquel Raynal Stable-dep-of: df6f582df337 ("mtd: intel-dg: Fix runtime PM error path in probe") Signed-off-by: Sasha Levin