linux-stable.git/drivers/mtd, branch linux-5.17.y Linux kernel stable tree ubi: ubi_create_volume: Fix use-after-free when volume creation failed 2022-06-14T16:41:22+00:00 Zhihao Cheng chengzhihao1@huawei.com 2022-05-10T12:31:26+00:00 e27ecf325e51abd06aaefba57a6322a46fa4178b [ Upstream commit 8c03a1c21d72210f81cb369cc528e3fde4b45411 ] There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s error handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tbl out_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAF Fix it by removing redundant 'eba_tbl' releasing. Fetch a reproducer in [Link]. Fixes: 493cfaeaa0c9b ("mtd: utilize new cdev_device_add helper function") Link: https://bugzilla.kernel.org/show_bug.cgi?id=215965 Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8c03a1c21d72210f81cb369cc528e3fde4b45411 ]

There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s
error handling path:

  ubi_eba_replace_table(vol, eba_tbl)
    vol->eba_tbl = tbl
out_mapping:
  ubi_eba_destroy_table(eba_tbl)   // Free 'eba_tbl'
out_unlock:
  put_device(&vol->dev)
    vol_release
      kfree(tbl->entries)	  // UAF

Fix it by removing redundant 'eba_tbl' releasing.
Fetch a reproducer in [Link].

Fixes: 493cfaeaa0c9b ("mtd: utilize new cdev_device_add helper function")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215965
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ubi: fastmap: Fix high cpu usage of ubi_bgt by making sure wl_pool not empty 2022-06-14T16:41:21+00:00 Zhihao Cheng chengzhihao1@huawei.com 2022-05-10T12:31:24+00:00 794c698e38d8510ec4ff3e265af32a4350bd6301 [ Upstream commit d09e9a2bddba6c48e0fddb16c4383172ac593251 ] There at least 6 PEBs reserved on UBI device: 1. EBA_RESERVED_PEBS[1] 2. WL_RESERVED_PEBS[1] 3. UBI_LAYOUT_VOLUME_EBS[2] 4. MIN_FASTMAP_RESERVED_PEBS[2] When all ubi volumes take all their PEBs, there are 3 (EBA_RESERVED_PEBS + WL_RESERVED_PEBS + MIN_FASTMAP_RESERVED_PEBS - MIN_FASTMAP_TAKEN_PEBS[1]) free PEBs. Since commit f9c34bb529975fe ("ubi: Fix producing anchor PEBs") and commit 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs considering wear level rules") applied, there is only 1 (3 - FASTMAP_ANCHOR_PEBS[1] - FASTMAP_NEXT_ANCHOR_PEBS[1]) free PEB to fill pool and wl_pool, after filling pool, wl_pool is always empty. So, UBI could be stuck in an infinite loop: ubi_thread system_wq wear_leveling_worker <-------------------------------------------------- get_peb_for_wl | // fm_wl_pool, used = size = 0 | schedule_work(&ubi->fm_work) | | update_fastmap_work_fn | ubi_update_fastmap | ubi_refill_pools | // ubi->free_count - ubi->beb_rsvd_pebs < 5 | // wl_pool is not filled with any PEBs | schedule_erase(old_fm_anchor) | ubi_ensure_anchor_pebs | __schedule_ubi_work(wear_leveling_worker) | | __erase_worker | ensure_wear_leveling | __schedule_ubi_work(wear_leveling_worker) -------------------------- , which cause high cpu usage of ubi_bgt: top - 12:10:42 up 5 min, 2 users, load average: 1.76, 0.68, 0.27 Tasks: 123 total, 3 running, 54 sleeping, 0 stopped, 0 zombie PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1589 root 20 0 0 0 0 R 45.0 0.0 0:38.86 ubi_bgt0d 319 root 20 0 0 0 0 I 15.2 0.0 0:15.29 kworker/0:3-eve 371 root 20 0 0 0 0 I 14.9 0.0 0:12.85 kworker/3:3-eve 20 root 20 0 0 0 0 I 11.3 0.0 0:05.33 kworker/1:0-eve 202 root 20 0 0 0 0 I 11.3 0.0 0:04.93 kworker/2:3-eve In commit 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs considering wear level rules"), there are three key changes: 1) Choose the fastmap anchor when the most free PEBs are available. 2) Enable anchor move within the anchor area again as it is useful for distributing wear. 3) Import a candidate fm anchor and check this PEB's erase count during wear leveling. If the wear leveling limit is exceeded, use the used anchor area PEB with the lowest erase count to replace it. The anchor candidate can be removed, we can check fm_anchor PEB's erase count during wear leveling. Fix it by: 1) Removing 'fm_next_anchor' and check 'fm_anchor' during wear leveling. 2) Preferentially filling one free peb into fm_wl_pool in condition of ubi->free_count > ubi->beb_rsvd_pebs, then try to reserve enough free count for fastmap non anchor pebs after the above prerequisites are met. Then, there are at least 1 PEB in pool and 1 PEB in wl_pool after calling ubi_refill_pools() with all erase works done. Fetch a reproducer in [Link]. Fixes: 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs ... rules") Link: https://bugzilla.kernel.org/show_bug.cgi?id=215407 Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d09e9a2bddba6c48e0fddb16c4383172ac593251 ]

There at least 6 PEBs reserved on UBI device:
1. EBA_RESERVED_PEBS[1]
2. WL_RESERVED_PEBS[1]
3. UBI_LAYOUT_VOLUME_EBS[2]
4. MIN_FASTMAP_RESERVED_PEBS[2]

When all ubi volumes take all their PEBs, there are 3 (EBA_RESERVED_PEBS +
WL_RESERVED_PEBS + MIN_FASTMAP_RESERVED_PEBS - MIN_FASTMAP_TAKEN_PEBS[1])
free PEBs. Since commit f9c34bb529975fe ("ubi: Fix producing anchor PEBs")
and commit 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs considering
wear level rules") applied, there is only 1 (3 - FASTMAP_ANCHOR_PEBS[1] -
FASTMAP_NEXT_ANCHOR_PEBS[1]) free PEB to fill pool and wl_pool, after
filling pool, wl_pool is always empty. So, UBI could be stuck in an
infinite loop:

	ubi_thread	   system_wq
wear_leveling_worker <--------------------------------------------------
  get_peb_for_wl							|
    // fm_wl_pool, used = size = 0					|
    schedule_work(&ubi->fm_work)					|
									|
		    update_fastmap_work_fn				|
		      ubi_update_fastmap				|
			ubi_refill_pools				|
			// ubi->free_count - ubi->beb_rsvd_pebs < 5	|
			// wl_pool is not filled with any PEBs		|
			schedule_erase(old_fm_anchor)			|
			ubi_ensure_anchor_pebs				|
			  __schedule_ubi_work(wear_leveling_worker)	|
									|
__erase_worker								|
  ensure_wear_leveling							|
    __schedule_ubi_work(wear_leveling_worker) --------------------------

, which cause high cpu usage of ubi_bgt:
top - 12:10:42 up 5 min,  2 users,  load average: 1.76, 0.68, 0.27
Tasks: 123 total,   3 running,  54 sleeping,   0 stopped,   0 zombie

  PID USER PR   NI VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1589 root 20   0   0      0      0 R  45.0  0.0   0:38.86 ubi_bgt0d
  319 root 20   0   0      0      0 I  15.2  0.0   0:15.29 kworker/0:3-eve
  371 root 20   0   0      0      0 I  14.9  0.0   0:12.85 kworker/3:3-eve
   20 root 20   0   0      0      0 I  11.3  0.0   0:05.33 kworker/1:0-eve
  202 root 20   0   0      0      0 I  11.3  0.0   0:04.93 kworker/2:3-eve

In commit 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs considering
wear level rules"), there are three key changes:
  1) Choose the fastmap anchor when the most free PEBs are available.
  2) Enable anchor move within the anchor area again as it is useful
     for distributing wear.
  3) Import a candidate fm anchor and check this PEB's erase count during
     wear leveling. If the wear leveling limit is exceeded, use the used
     anchor area PEB with the lowest erase count to replace it.

The anchor candidate can be removed, we can check fm_anchor PEB's erase
count during wear leveling. Fix it by:
  1) Removing 'fm_next_anchor' and check 'fm_anchor' during wear leveling.
  2) Preferentially filling one free peb into fm_wl_pool in condition of
     ubi->free_count > ubi->beb_rsvd_pebs, then try to reserve enough
     free count for fastmap non anchor pebs after the above prerequisites
     are met.
Then, there are at least 1 PEB in pool and 1 PEB in wl_pool after calling
ubi_refill_pools() with all erase works done.

Fetch a reproducer in [Link].

Fixes: 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs ... rules")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215407
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: cfi_cmdset_0002: Use chip_ready() for write on S29GL064N 2022-06-09T08:26:25+00:00 Tokunori Ikegami ikegami.t@gmail.com 2022-03-23T17:04:56+00:00 76d0571e47cacda2d571f8698a5134a71cff68d2 commit 0a8e98305f63deaf0a799d5cf5532cc83af035d1 upstream. Since commit dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") buffered writes fail on S29GL064N. This is because, on S29GL064N, reads return 0xFF at the end of DQ polling for write completion, where as, chip_good() check expects actual data written to the last location to be returned post DQ polling completion. Fix is to revert to using chip_good() for S29GL064N which only checks for DQ lines to settle down to determine write completion. Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.de/ Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") Cc: stable@vger.kernel.org Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-3-ikegami.t@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 0a8e98305f63deaf0a799d5cf5532cc83af035d1 upstream.

Since commit dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to
check correct value") buffered writes fail on S29GL064N. This is
because, on S29GL064N, reads return 0xFF at the end of DQ polling for
write completion, where as, chip_good() check expects actual data
written to the last location to be returned post DQ polling completion.
Fix is to revert to using chip_good() for S29GL064N which only checks
for DQ lines to settle down to determine write completion.

Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.de/
Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value")
Cc: stable@vger.kernel.org
Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-3-ikegami.t@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mtd: cfi_cmdset_0002: Move and rename chip_check/chip_ready/chip_good_for_write 2022-06-09T08:26:25+00:00 Tokunori Ikegami ikegami.t@gmail.com 2022-03-23T17:04:55+00:00 2bed5287656b00fb31fd036a05b417e527e54e09 commit 083084df578a8bdb18334f69e7b32d690aaa3247 upstream. This is a preparation patch for the S29GL064N buffer writes fix. There is no functional change. Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.de/ Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com> Cc: stable@vger.kernel.org Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-2-ikegami.t@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 083084df578a8bdb18334f69e7b32d690aaa3247 upstream.

This is a preparation patch for the S29GL064N buffer writes fix. There
is no functional change.

Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.de/
Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value")
Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
Cc: stable@vger.kernel.org
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-2-ikegami.t@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mtd: rawnand: intel: fix possible null-ptr-deref in ebu_nand_probe() 2022-06-09T08:25:44+00:00 Yang Yingliang yangyingliang@huawei.com 2022-04-26T08:49:12+00:00 daa5166450b447415aeeaac0199e445bae7bd0f2 [ Upstream commit ddf66aefd685fd46500b9917333e1b1e118276dc ] It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. Fixes: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220426084913.4021868-2-yangyingliang@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ddf66aefd685fd46500b9917333e1b1e118276dc ]

It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.

Fixes: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220426084913.4021868-2-yangyingliang@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe() 2022-06-09T08:25:44+00:00 Yang Yingliang yangyingliang@huawei.com 2022-04-26T08:49:11+00:00 069af5e27c1b0f7677ef76d8d3102e503ca4f80b [ Upstream commit a28ed09dafee20da51eb26452950839633afd824 ] It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220426084913.4021868-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit a28ed09dafee20da51eb26452950839633afd824 ]

It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code.

Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220426084913.4021868-1-yangyingliang@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: spi-nor: core: Check written SR value in spi_nor_write_16bit_sr_and_check() 2022-06-09T08:25:44+00:00 Chen-Tsung Hsieh chentsung@chromium.org 2022-01-26T07:32:26+00:00 ca3f0824f28f7d85e99f71a973c02b7672d54d44 [ Upstream commit 70dd83d737d8900b2d98db6dc6b928c596334d37 ] Read back Status Register 1 to ensure that the written byte match the received value and return -EIO if read back test failed. Without this patch, spi_nor_write_16bit_sr_and_check() only check the second half of the 16bit. It causes errors like spi_nor_sr_unlock() return success incorrectly when spi_nor_write_16bit_sr_and_check() doesn't write SR successfully. Fixes: 39d1e3340c73 ("mtd: spi-nor: Fix clearing of QE bit on lock()/unlock()") Signed-off-by: Chen-Tsung Hsieh <chentsung@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Michael Walle <michael@walle.cc> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Acked-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20220126073227.3401275-1-chentsung@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 70dd83d737d8900b2d98db6dc6b928c596334d37 ]

Read back Status Register 1 to ensure that the written byte match the
received value and return -EIO if read back test failed.

Without this patch, spi_nor_write_16bit_sr_and_check() only check the
second half of the 16bit. It causes errors like spi_nor_sr_unlock()
return success incorrectly when spi_nor_write_16bit_sr_and_check()
doesn't write SR successfully.

Fixes: 39d1e3340c73 ("mtd: spi-nor: Fix clearing of QE bit on lock()/unlock()")
Signed-off-by: Chen-Tsung Hsieh <chentsung@chromium.org>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Acked-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20220126073227.3401275-1-chentsung@chromium.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtdblock: warn if opened on NAND 2022-06-09T08:25:42+00:00 Bjørn Mork bjorn@mork.no 2022-03-28T16:11:08+00:00 78662c08919a2ff456e26d7fae378d3a35b6dc82 [ Upstream commit 96a3295c351da82d7af99b2fc004a3cf9f4716a9 ] Warning on every translated mtd partition results in excessive log noise if this driver is loaded: nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 nand: Macronix MX30LF1G18AC nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits read_bbt: found bbt at block 1023 10 fixed-partitions partitions found on MTD device mt7621-nand Creating 10 MTD partitions on "mt7621-nand": 0x000000000000-0x000000080000 : "Bootloader" mtdblock: MTD device 'Bootloader' is NAND, please consider using UBI block devices instead. 0x000000080000-0x000000100000 : "Config" mtdblock: MTD device 'Config' is NAND, please consider using UBI block devices instead. 0x000000100000-0x000000140000 : "Factory" mtdblock: MTD device 'Factory' is NAND, please consider using UBI block devices instead. 0x000000140000-0x000002000000 : "Kernel" mtdblock: MTD device 'Kernel' is NAND, please consider using UBI block devices instead. 0x000000540000-0x000002000000 : "ubi" mtdblock: MTD device 'ubi' is NAND, please consider using UBI block devices instead. 0x000002140000-0x000004000000 : "Kernel2" mtdblock: MTD device 'Kernel2' is NAND, please consider using UBI block devices instead. 0x000004000000-0x000004100000 : "wwan" mtdblock: MTD device 'wwan' is NAND, please consider using UBI block devices instead. 0x000004100000-0x000005100000 : "data" mtdblock: MTD device 'data' is NAND, please consider using UBI block devices instead. 0x000005100000-0x000005200000 : "rom-d" mtdblock: MTD device 'rom-d' is NAND, please consider using UBI block devices instead. 0x000005200000-0x000005280000 : "reserve" mtdblock: MTD device 'reserve' is NAND, please consider using UBI block devices instead. mtk_soc_eth 1e100000.ethernet eth0: mediatek frame engine at 0xbe100000, irq 21 This is more likely to annoy than to help users of embedded distros where this driver is enabled by default. Making the blockdevs available does not imply that they are in use, and warning about bootloader partitions or other devices which obviously never will be mounted is more confusing than helpful. Move the warning to open(), where it will be of more use - actually warning anyone who mounts a file system on NAND using mtdblock. Fixes: e07403a8c6be ("mtdblock: Warn if added for a NAND device") Signed-off-by: Bjørn Mork <bjorn@mork.no> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220328161108.87757-1-bjorn@mork.no Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 96a3295c351da82d7af99b2fc004a3cf9f4716a9 ]

Warning on every translated mtd partition results in excessive log noise
if this driver is loaded:

  nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
  nand: Macronix MX30LF1G18AC
  nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
  mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits
  read_bbt: found bbt at block 1023
  10 fixed-partitions partitions found on MTD device mt7621-nand
  Creating 10 MTD partitions on "mt7621-nand":
  0x000000000000-0x000000080000 : "Bootloader"
  mtdblock: MTD device 'Bootloader' is NAND, please consider using UBI block devices instead.
  0x000000080000-0x000000100000 : "Config"
  mtdblock: MTD device 'Config' is NAND, please consider using UBI block devices instead.
  0x000000100000-0x000000140000 : "Factory"
  mtdblock: MTD device 'Factory' is NAND, please consider using UBI block devices instead.
  0x000000140000-0x000002000000 : "Kernel"
  mtdblock: MTD device 'Kernel' is NAND, please consider using UBI block devices instead.
  0x000000540000-0x000002000000 : "ubi"
  mtdblock: MTD device 'ubi' is NAND, please consider using UBI block devices instead.
  0x000002140000-0x000004000000 : "Kernel2"
  mtdblock: MTD device 'Kernel2' is NAND, please consider using UBI block devices instead.
  0x000004000000-0x000004100000 : "wwan"
  mtdblock: MTD device 'wwan' is NAND, please consider using UBI block devices instead.
  0x000004100000-0x000005100000 : "data"
  mtdblock: MTD device 'data' is NAND, please consider using UBI block devices instead.
  0x000005100000-0x000005200000 : "rom-d"
  mtdblock: MTD device 'rom-d' is NAND, please consider using UBI block devices instead.
  0x000005200000-0x000005280000 : "reserve"
  mtdblock: MTD device 'reserve' is NAND, please consider using UBI block devices instead.
  mtk_soc_eth 1e100000.ethernet eth0: mediatek frame engine at 0xbe100000, irq 21

This is more likely to annoy than to help users of embedded distros where
this driver is enabled by default.  Making the blockdevs available does
not imply that they are in use, and warning about bootloader partitions
or other devices which obviously never will be mounted is more confusing
than helpful.

Move the warning to open(), where it will be of more use - actually warning
anyone who mounts a file system on NAND using mtdblock.

Fixes: e07403a8c6be ("mtdblock: Warn if added for a NAND device")
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220328161108.87757-1-bjorn@mork.no
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: rawnand: denali: Use managed device resources 2022-06-09T08:25:40+00:00 Zheyu Ma zheyuma97@gmail.com 2022-04-11T12:58:08+00:00 87149cf9186201a63f0e0b93d9fa93d480bcb771 [ Upstream commit 3a745b51cddafade99aaea1b93aad31e9614e230 ] All of the resources used by this driver has managed interfaces, so use them. Otherwise we will get the following splat: [ 4.472703] denali-nand-pci 0000:00:05.0: timeout while waiting for irq 0x1000 [ 4.474071] denali-nand-pci: probe of 0000:00:05.0 failed with error -5 [ 4.473538] nand: No NAND device found [ 4.474068] BUG: unable to handle page fault for address: ffffc90005000410 [ 4.475169] #PF: supervisor write access in kernel mode [ 4.475579] #PF: error_code(0x0002) - not-present page [ 4.478362] RIP: 0010:iowrite32+0x9/0x50 [ 4.486068] Call Trace: [ 4.486269] <IRQ> [ 4.486443] denali_isr+0x15b/0x300 [denali] [ 4.486788] ? denali_direct_write+0x50/0x50 [denali] [ 4.487189] __handle_irq_event_percpu+0x161/0x3b0 [ 4.487571] handle_irq_event+0x7d/0x1b0 [ 4.487884] handle_fasteoi_irq+0x2b0/0x770 [ 4.488219] __common_interrupt+0xc8/0x1b0 [ 4.488549] common_interrupt+0x9a/0xc0 Fixes: 93db446a424c ("mtd: nand: move raw NAND related code to the raw/ subdir") Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220411125808.958276-1-zheyuma97@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3a745b51cddafade99aaea1b93aad31e9614e230 ]

All of the resources used by this driver has managed interfaces, so use
them. Otherwise we will get the following splat:

[    4.472703] denali-nand-pci 0000:00:05.0: timeout while waiting for irq 0x1000
[    4.474071] denali-nand-pci: probe of 0000:00:05.0 failed with error -5
[    4.473538] nand: No NAND device found
[    4.474068] BUG: unable to handle page fault for address: ffffc90005000410
[    4.475169] #PF: supervisor write access in kernel mode
[    4.475579] #PF: error_code(0x0002) - not-present page
[    4.478362] RIP: 0010:iowrite32+0x9/0x50
[    4.486068] Call Trace:
[    4.486269]  <IRQ>
[    4.486443]  denali_isr+0x15b/0x300 [denali]
[    4.486788]  ? denali_direct_write+0x50/0x50 [denali]
[    4.487189]  __handle_irq_event_percpu+0x161/0x3b0
[    4.487571]  handle_irq_event+0x7d/0x1b0
[    4.487884]  handle_fasteoi_irq+0x2b0/0x770
[    4.488219]  __common_interrupt+0xc8/0x1b0
[    4.488549]  common_interrupt+0x9a/0xc0

Fixes: 93db446a424c ("mtd: nand: move raw NAND related code to the raw/ subdir")
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220411125808.958276-1-zheyuma97@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: spinand: gigadevice: fix Quad IO for GD5F1GQ5UExxG 2022-06-09T08:25:37+00:00 Chuanhong Guo gch981213@gmail.com 2022-03-20T09:59:57+00:00 2f10820f29ead5418cae6123e10c5c0c82637115 [ Upstream commit a4f9dd55c5e1bb951db6f1dee20e62e0103f3438 ] Read From Cache Quad IO (EBH) uses 2 dummy bytes on this chip according to page 23 of the datasheet[0]. [0]: https://www.gigadevice.com/datasheet/gd5f1gq5xexxg/ Fixes: 469b99248985 ("mtd: spinand: gigadevice: Support GD5F1GQ5UExxG") Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220320100001.247905-2-gch981213@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit a4f9dd55c5e1bb951db6f1dee20e62e0103f3438 ]

Read From Cache Quad IO (EBH) uses 2 dummy bytes on this chip according
to page 23 of the datasheet[0].

[0]: https://www.gigadevice.com/datasheet/gd5f1gq5xexxg/

Fixes: 469b99248985 ("mtd: spinand: gigadevice: Support GD5F1GQ5UExxG")
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220320100001.247905-2-gch981213@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>