<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mtd, branch v5.18.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mtd: cfi_cmdset_0002: Use chip_ready() for write on S29GL064N</title>
<updated>2022-06-09T08:30:49+00:00</updated>
<author>
<name>Tokunori Ikegami</name>
<email>ikegami.t@gmail.com</email>
</author>
<published>2022-03-23T17:04:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cabcce1f1b371e97bbfd7a434573a3512ca5629d'/>
<id>cabcce1f1b371e97bbfd7a434573a3512ca5629d</id>
<content type='text'>
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 &lt;ikegami.t@gmail.com&gt;
Acked-by: Vignesh Raghavendra &lt;vigneshr@ti.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-3-ikegami.t@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;ikegami.t@gmail.com&gt;
Acked-by: Vignesh Raghavendra &lt;vigneshr@ti.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-3-ikegami.t@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: cfi_cmdset_0002: Move and rename chip_check/chip_ready/chip_good_for_write</title>
<updated>2022-06-09T08:30:49+00:00</updated>
<author>
<name>Tokunori Ikegami</name>
<email>ikegami.t@gmail.com</email>
</author>
<published>2022-03-23T17:04:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a9da23660fb4ee24d1f4581f7854401181b312d1'/>
<id>a9da23660fb4ee24d1f4581f7854401181b312d1</id>
<content type='text'>
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 &lt;ikegami.t@gmail.com&gt;
Cc: stable@vger.kernel.org
Acked-by: Vignesh Raghavendra &lt;vigneshr@ti.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-2-ikegami.t@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;ikegami.t@gmail.com&gt;
Cc: stable@vger.kernel.org
Acked-by: Vignesh Raghavendra &lt;vigneshr@ti.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-2-ikegami.t@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: rawnand: intel: fix possible null-ptr-deref in ebu_nand_probe()</title>
<updated>2022-06-09T08:30:04+00:00</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2022-04-26T08:49:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f8e262eb7575a4a2412f30f7a1b293875aceba80'/>
<id>f8e262eb7575a4a2412f30f7a1b293875aceba80</id>
<content type='text'>
[ 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 &lt;yangyingliang@huawei.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220426084913.4021868-2-yangyingliang@huawei.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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 &lt;yangyingliang@huawei.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220426084913.4021868-2-yangyingliang@huawei.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe()</title>
<updated>2022-06-09T08:30:04+00:00</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2022-04-26T08:49:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=13b60d3dc84b47307669edb66b633b18466014b4'/>
<id>13b60d3dc84b47307669edb66b633b18466014b4</id>
<content type='text'>
[ 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 &lt;yangyingliang@huawei.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220426084913.4021868-1-yangyingliang@huawei.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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 &lt;yangyingliang@huawei.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220426084913.4021868-1-yangyingliang@huawei.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: spi-nor: core: Check written SR value in spi_nor_write_16bit_sr_and_check()</title>
<updated>2022-06-09T08:30:03+00:00</updated>
<author>
<name>Chen-Tsung Hsieh</name>
<email>chentsung@chromium.org</email>
</author>
<published>2022-01-26T07:32:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0b3ca36c7b2dee23e99d45c02876d90aacf06534'/>
<id>0b3ca36c7b2dee23e99d45c02876d90aacf06534</id>
<content type='text'>
[ 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 &lt;chentsung@chromium.org&gt;
Signed-off-by: Pratyush Yadav &lt;p.yadav@ti.com&gt;
Reviewed-by: Michael Walle &lt;michael@walle.cc&gt;
Reviewed-by: Tudor Ambarus &lt;tudor.ambarus@microchip.com&gt;
Acked-by: Pratyush Yadav &lt;p.yadav@ti.com&gt;
Link: https://lore.kernel.org/r/20220126073227.3401275-1-chentsung@chromium.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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 &lt;chentsung@chromium.org&gt;
Signed-off-by: Pratyush Yadav &lt;p.yadav@ti.com&gt;
Reviewed-by: Michael Walle &lt;michael@walle.cc&gt;
Reviewed-by: Tudor Ambarus &lt;tudor.ambarus@microchip.com&gt;
Acked-by: Pratyush Yadav &lt;p.yadav@ti.com&gt;
Link: https://lore.kernel.org/r/20220126073227.3401275-1-chentsung@chromium.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtdblock: warn if opened on NAND</title>
<updated>2022-06-09T08:30:02+00:00</updated>
<author>
<name>Bjørn Mork</name>
<email>bjorn@mork.no</email>
</author>
<published>2022-03-28T16:11:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a009e714cfe648e74f2b252a886f59920703faf1'/>
<id>a009e714cfe648e74f2b252a886f59920703faf1</id>
<content type='text'>
[ 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 &lt;bjorn@mork.no&gt;
Reviewed-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220328161108.87757-1-bjorn@mork.no
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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 &lt;bjorn@mork.no&gt;
Reviewed-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220328161108.87757-1-bjorn@mork.no
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: rawnand: denali: Use managed device resources</title>
<updated>2022-06-09T08:29:59+00:00</updated>
<author>
<name>Zheyu Ma</name>
<email>zheyuma97@gmail.com</email>
</author>
<published>2022-04-11T12:58:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=efea1dd176edd17c8252051b7de6957f06efc394'/>
<id>efea1dd176edd17c8252051b7de6957f06efc394</id>
<content type='text'>
[ 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]  &lt;IRQ&gt;
[    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 &lt;zheyuma97@gmail.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220411125808.958276-1-zheyuma97@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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]  &lt;IRQ&gt;
[    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 &lt;zheyuma97@gmail.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220411125808.958276-1-zheyuma97@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: spinand: gigadevice: fix Quad IO for GD5F1GQ5UExxG</title>
<updated>2022-06-09T08:29:55+00:00</updated>
<author>
<name>Chuanhong Guo</name>
<email>gch981213@gmail.com</email>
</author>
<published>2022-03-20T09:59:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f84d6054fd58f9d130ea4a4e9bde989d982c0dc5'/>
<id>f84d6054fd58f9d130ea4a4e9bde989d982c0dc5</id>
<content type='text'>
[ 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 &lt;gch981213@gmail.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220320100001.247905-2-gch981213@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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 &lt;gch981213@gmail.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220320100001.247905-2-gch981213@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: rawnand: qcom: fix memory corruption that causes panic</title>
<updated>2022-04-21T07:29:07+00:00</updated>
<author>
<name>Md Sadre Alam</name>
<email>quic_mdalam@quicinc.com</email>
</author>
<published>2022-04-18T07:48:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ba7542eb2dd5dfc75c457198b88986642e602065'/>
<id>ba7542eb2dd5dfc75c457198b88986642e602065</id>
<content type='text'>
This patch fixes a memory corruption that occurred in the
nand_scan() path for Hynix nand device.

On boot, for Hynix nand device will panic at a weird place:
| Unable to handle kernel NULL pointer dereference at virtual
  address 00000070
| [00000070] *pgd=00000000
| Internal error: Oops: 5 [#1] PREEMPT SMP ARM
| Modules linked in:
| CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-01473-g13ae1769cfb0
  #38
| Hardware name: Generic DT based system
| PC is at nandc_set_reg+0x8/0x1c
| LR is at qcom_nandc_command+0x20c/0x5d0
| pc : [&lt;c088b74c&gt;]    lr : [&lt;c088d9c8&gt;]    psr: 00000113
| sp : c14adc50  ip : c14ee208  fp : c0cc970c
| r10: 000000a3  r9 : 00000000  r8 : 00000040
| r7 : c16f6a00  r6 : 00000090  r5 : 00000004  r4 :c14ee040
| r3 : 00000000  r2 : 0000000b  r1 : 00000000  r0 :c14ee040
| Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment none
| Control: 10c5387d  Table: 8020406a  DAC: 00000051
| Register r0 information: slab kmalloc-2k start c14ee000 pointer offset
  64 size 2048
| Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
| nandc_set_reg from qcom_nandc_command+0x20c/0x5d0
| qcom_nandc_command from nand_readid_op+0x198/0x1e8
| nand_readid_op from hynix_nand_has_valid_jedecid+0x30/0x78
| hynix_nand_has_valid_jedecid from hynix_nand_init+0xb8/0x454
| hynix_nand_init from nand_scan_with_ids+0xa30/0x14a8
| nand_scan_with_ids from qcom_nandc_probe+0x648/0x7b0
| qcom_nandc_probe from platform_probe+0x58/0xac

The problem is that the nand_scan()'s qcom_nand_attach_chip callback
is updating the nandc-&gt;max_cwperpage from 1 to 4 or 8 based on page size.
This causes the sg_init_table of clear_bam_transaction() in the driver's
qcom_nandc_command() to memset much more than what was initially
allocated by alloc_bam_transaction().

This patch will update nandc-&gt;max_cwperpage 1 to 4 or 8 based on page
size in qcom_nand_attach_chip call back after freeing the previously
allocated memory for bam txn as per nandc-&gt;max_cwperpage = 1 and then
again allocating bam txn as per nandc-&gt;max_cwperpage = 4 or 8 based on
page size in qcom_nand_attach_chip call back itself.

Cc: stable@vger.kernel.org
Fixes: 6a3cec64f18c ("mtd: rawnand: qcom: convert driver to nand_scan()")
Reported-by: Konrad Dybcio &lt;konrad.dybcio@somainline.org&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Co-developed-by: Sricharan R &lt;quic_srichara@quicinc.com&gt;
Signed-off-by: Sricharan R &lt;quic_srichara@quicinc.com&gt;
Signed-off-by: Md Sadre Alam &lt;quic_mdalam@quicinc.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/1650268107-5363-1-git-send-email-quic_mdalam@quicinc.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes a memory corruption that occurred in the
nand_scan() path for Hynix nand device.

On boot, for Hynix nand device will panic at a weird place:
| Unable to handle kernel NULL pointer dereference at virtual
  address 00000070
| [00000070] *pgd=00000000
| Internal error: Oops: 5 [#1] PREEMPT SMP ARM
| Modules linked in:
| CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-01473-g13ae1769cfb0
  #38
| Hardware name: Generic DT based system
| PC is at nandc_set_reg+0x8/0x1c
| LR is at qcom_nandc_command+0x20c/0x5d0
| pc : [&lt;c088b74c&gt;]    lr : [&lt;c088d9c8&gt;]    psr: 00000113
| sp : c14adc50  ip : c14ee208  fp : c0cc970c
| r10: 000000a3  r9 : 00000000  r8 : 00000040
| r7 : c16f6a00  r6 : 00000090  r5 : 00000004  r4 :c14ee040
| r3 : 00000000  r2 : 0000000b  r1 : 00000000  r0 :c14ee040
| Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment none
| Control: 10c5387d  Table: 8020406a  DAC: 00000051
| Register r0 information: slab kmalloc-2k start c14ee000 pointer offset
  64 size 2048
| Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
| nandc_set_reg from qcom_nandc_command+0x20c/0x5d0
| qcom_nandc_command from nand_readid_op+0x198/0x1e8
| nand_readid_op from hynix_nand_has_valid_jedecid+0x30/0x78
| hynix_nand_has_valid_jedecid from hynix_nand_init+0xb8/0x454
| hynix_nand_init from nand_scan_with_ids+0xa30/0x14a8
| nand_scan_with_ids from qcom_nandc_probe+0x648/0x7b0
| qcom_nandc_probe from platform_probe+0x58/0xac

The problem is that the nand_scan()'s qcom_nand_attach_chip callback
is updating the nandc-&gt;max_cwperpage from 1 to 4 or 8 based on page size.
This causes the sg_init_table of clear_bam_transaction() in the driver's
qcom_nandc_command() to memset much more than what was initially
allocated by alloc_bam_transaction().

This patch will update nandc-&gt;max_cwperpage 1 to 4 or 8 based on page
size in qcom_nand_attach_chip call back after freeing the previously
allocated memory for bam txn as per nandc-&gt;max_cwperpage = 1 and then
again allocating bam txn as per nandc-&gt;max_cwperpage = 4 or 8 based on
page size in qcom_nand_attach_chip call back itself.

Cc: stable@vger.kernel.org
Fixes: 6a3cec64f18c ("mtd: rawnand: qcom: convert driver to nand_scan()")
Reported-by: Konrad Dybcio &lt;konrad.dybcio@somainline.org&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Co-developed-by: Sricharan R &lt;quic_srichara@quicinc.com&gt;
Signed-off-by: Sricharan R &lt;quic_srichara@quicinc.com&gt;
Signed-off-by: Md Sadre Alam &lt;quic_mdalam@quicinc.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/1650268107-5363-1-git-send-email-quic_mdalam@quicinc.com
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: rawnand: Fix return value check of wait_for_completion_timeout</title>
<updated>2022-04-21T07:29:03+00:00</updated>
<author>
<name>Miaoqian Lin</name>
<email>linmq006@gmail.com</email>
</author>
<published>2022-04-12T08:34:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=084c16ab423a8890121b902b405823bfec5b4365'/>
<id>084c16ab423a8890121b902b405823bfec5b4365</id>
<content type='text'>
wait_for_completion_timeout() returns unsigned long not int.
It returns 0 if timed out, and positive if completed.
The check for &lt;= 0 is ambiguous and should be == 0 here
indicating timeout which is the only error case.

Fixes: 83738d87e3a0 ("mtd: sh_flctl: Add DMA capabilty")
Signed-off-by: Miaoqian Lin &lt;linmq006@gmail.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220412083435.29254-1-linmq006@gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
wait_for_completion_timeout() returns unsigned long not int.
It returns 0 if timed out, and positive if completed.
The check for &lt;= 0 is ambiguous and should be == 0 here
indicating timeout which is the only error case.

Fixes: 83738d87e3a0 ("mtd: sh_flctl: Add DMA capabilty")
Signed-off-by: Miaoqian Lin &lt;linmq006@gmail.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20220412083435.29254-1-linmq006@gmail.com
</pre>
</div>
</content>
</entry>
</feed>
