<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mtd, branch v3.12.20</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mtd: sm_ftl: heap corruption in sm_create_sysfs_attributes()</title>
<updated>2014-05-15T07:56:11+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2013-12-05T14:53:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=16a7c07c715dc5d8b764b2c3cae3b43117c01de3'/>
<id>16a7c07c715dc5d8b764b2c3cae3b43117c01de3</id>
<content type='text'>
commit b4c233057771581698a13694ab6f33b48ce837dc upstream.

We always put a NUL terminator one space past the end of the "vendor"
buffer.  Walter Harms also pointed out that this should just use
kstrndup().

Fixes: 7d17c02a01a1 ('mtd: Add new SmartMedia/xD FTL')

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b4c233057771581698a13694ab6f33b48ce837dc upstream.

We always put a NUL terminator one space past the end of the "vendor"
buffer.  Walter Harms also pointed out that this should just use
kstrndup().

Fixes: 7d17c02a01a1 ('mtd: Add new SmartMedia/xD FTL')

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: nuc900_nand: NULL dereference in nuc900_nand_enable()</title>
<updated>2014-05-15T07:56:11+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2014-02-17T20:03:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a46c32362ed74b19462c553604726e271c89b01f'/>
<id>a46c32362ed74b19462c553604726e271c89b01f</id>
<content type='text'>
commit c69dbbf3335a21aae74376d7e5db50a486d52439 upstream.

Instead of writing to "nand-&gt;reg + REG_FMICSR" we write to "REG_FMICSR"
which is NULL and not a valid register.

Fixes: 8bff82cbc308 ('mtd: add nand support for w90p910 (v2)')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c69dbbf3335a21aae74376d7e5db50a486d52439 upstream.

Instead of writing to "nand-&gt;reg + REG_FMICSR" we write to "REG_FMICSR"
which is NULL and not a valid register.

Fixes: 8bff82cbc308 ('mtd: add nand support for w90p910 (v2)')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: atmel_nand: Disable subpage NAND write when using Atmel PMECC</title>
<updated>2014-05-15T07:56:10+00:00</updated>
<author>
<name>Herve Codina</name>
<email>Herve.CODINA@celad.com</email>
</author>
<published>2014-03-03T11:15:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bf1490bcaaef902ab5fa9451f6087873c0568655'/>
<id>bf1490bcaaef902ab5fa9451f6087873c0568655</id>
<content type='text'>
commit 90445ff6241e2a13445310803e2efa606c61f276 upstream.

Crash detected on sam5d35 and its pmecc nand ecc controller.

The problem was a call to chip-&gt;ecc.hwctl from nand_write_subpage_hwecc
(nand_base.c) when we write a sub page.
chip-&gt;ecc.hwctl function is not set when we are using PMECC controller.
As a workaround, set NAND_NO_SUBPAGE_WRITE for PMECC controller in
order to disable sub page access in nand_write_page.

Signed-off-by: Herve Codina &lt;Herve.CODINA@celad.com&gt;
Acked-by: Josh Wu &lt;josh.wu@atmel.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 90445ff6241e2a13445310803e2efa606c61f276 upstream.

Crash detected on sam5d35 and its pmecc nand ecc controller.

The problem was a call to chip-&gt;ecc.hwctl from nand_write_subpage_hwecc
(nand_base.c) when we write a sub page.
chip-&gt;ecc.hwctl function is not set when we are using PMECC controller.
As a workaround, set NAND_NO_SUBPAGE_WRITE for PMECC controller in
order to disable sub page access in nand_write_page.

Signed-off-by: Herve Codina &lt;Herve.CODINA@celad.com&gt;
Acked-by: Josh Wu &lt;josh.wu@atmel.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: mxc_nand: remove duplicated ecc_stats counting</title>
<updated>2014-02-13T21:50:14+00:00</updated>
<author>
<name>Michael Grzeschik</name>
<email>m.grzeschik@pengutronix.de</email>
</author>
<published>2013-11-29T13:14:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9af6a8e68fd7c2469cfe50d1c982a8b8194259e8'/>
<id>9af6a8e68fd7c2469cfe50d1c982a8b8194259e8</id>
<content type='text'>
commit 0566477762f9e174e97af347ee9c865f908a5647 upstream.

The ecc_stats.corrected count variable will already be incremented in
the above framework-layer just after this callback.

Signed-off-by: Michael Grzeschik &lt;m.grzeschik@pengutronix.de&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
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 0566477762f9e174e97af347ee9c865f908a5647 upstream.

The ecc_stats.corrected count variable will already be incremented in
the above framework-layer just after this callback.

Signed-off-by: Michael Grzeschik &lt;m.grzeschik@pengutronix.de&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Partially revert "mtd: nand: pxa3xx: Introduce 'marvell,armada370-nand' compatible string"</title>
<updated>2013-12-20T15:48:57+00:00</updated>
<author>
<name>Ezequiel Garcia</name>
<email>ezequiel.garcia@free-electrons.com</email>
</author>
<published>2013-12-09T21:36:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=20a3008e850fc5b06595f3d850aea38c16213900'/>
<id>20a3008e850fc5b06595f3d850aea38c16213900</id>
<content type='text'>
commit 9c59ac616137fb62f6cb3f1219201b09cbcf30be upstream.

This partially reverts c0f3b8643a6fa2461d70760ec49d21d2b031d611.

The "armada370-nand" compatible support is not complete, and it was mistake
to add it. Revert it and postpone the support until the infrastructure is
in place.

Signed-off-by: Ezequiel Garcia &lt;ezequiel.garcia@free-electrons.com&gt;
Acked-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
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 9c59ac616137fb62f6cb3f1219201b09cbcf30be upstream.

This partially reverts c0f3b8643a6fa2461d70760ec49d21d2b031d611.

The "armada370-nand" compatible support is not complete, and it was mistake
to add it. Revert it and postpone the support until the infrastructure is
in place.

Signed-off-by: Ezequiel Garcia &lt;ezequiel.garcia@free-electrons.com&gt;
Acked-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: gpmi: fix the NULL pointer</title>
<updated>2013-12-04T19:05:25+00:00</updated>
<author>
<name>Huang Shijie</name>
<email>b32955@freescale.com</email>
</author>
<published>2013-11-12T04:23:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dba6d8ec7abae799b3e9ecf950318281937f8ff5'/>
<id>dba6d8ec7abae799b3e9ecf950318281937f8ff5</id>
<content type='text'>
commit 885d71e5838f68d5dbee92ab952cc90ad6c1dc6b upstream.

The imx23 board will check the fingerprint, so it will call the
mx23_check_transcription_stamp. This function will use @chip-&gt;buffers-&gt;databuf
as its buffer which is allocated in the nand_scan_tail().

Unfortunately, the mx23_check_transcription_stamp is called before the
nand_scan_tail(). So we will meet a NULL pointer bug:

--------------------------------------------------------------------
[    1.150000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xd7 (Samsung NAND 4GiB 3,3V 8-bit), 4096MiB, page size: 4096, OOB size: 8
[    1.160000] Unable to handle kernel NULL pointer dereference at virtual address 000005d0
[    1.170000] pgd = c0004000
[    1.170000] [000005d0] *pgd=00000000
[    1.180000] Internal error: Oops: 5 [#1] ARM
[    1.180000] Modules linked in:
[    1.180000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0 #89
[    1.180000] task: c7440000 ti: c743a000 task.ti: c743a000
[    1.180000] PC is at memcmp+0x10/0x54
[    1.180000] LR is at gpmi_nand_probe+0x42c/0x894
[    1.180000] pc : [&lt;c025fcb0&gt;]    lr : [&lt;c02f6a68&gt;]    psr: 20000053
[    1.180000] sp : c743be2c  ip : 600000d3  fp : ffffffff
[    1.180000] r10: 000005d0  r9 : c02f5f08  r8 : 00000000
[    1.180000] r7 : c75858a8  r6 : c75858a8  r5 : c7585b18  r4 : c7585800
[    1.180000] r3 : 000005d0  r2 : 00000004  r1 : c05c33e4  r0 : 000005d0
[    1.180000] Flags: nzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
[    1.180000] Control: 0005317f  Table: 40004000  DAC: 00000017
[    1.180000] Process swapper (pid: 1, stack limit = 0xc743a1c0)
--------------------------------------------------------------------

This patch rearrange the init procedure:
   Set the NAND_SKIP_BBTSCAN to skip the nand scan firstly, and after we
   set the proper settings, we will call the chip-&gt;scan_bbt() manually.

Signed-off-by: Huang Shijie &lt;b32955@freescale.com&gt;
Reported-by: Fabio Estevam &lt;festevam@gmail.com&gt;
Tested-by: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
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 885d71e5838f68d5dbee92ab952cc90ad6c1dc6b upstream.

The imx23 board will check the fingerprint, so it will call the
mx23_check_transcription_stamp. This function will use @chip-&gt;buffers-&gt;databuf
as its buffer which is allocated in the nand_scan_tail().

Unfortunately, the mx23_check_transcription_stamp is called before the
nand_scan_tail(). So we will meet a NULL pointer bug:

--------------------------------------------------------------------
[    1.150000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xd7 (Samsung NAND 4GiB 3,3V 8-bit), 4096MiB, page size: 4096, OOB size: 8
[    1.160000] Unable to handle kernel NULL pointer dereference at virtual address 000005d0
[    1.170000] pgd = c0004000
[    1.170000] [000005d0] *pgd=00000000
[    1.180000] Internal error: Oops: 5 [#1] ARM
[    1.180000] Modules linked in:
[    1.180000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0 #89
[    1.180000] task: c7440000 ti: c743a000 task.ti: c743a000
[    1.180000] PC is at memcmp+0x10/0x54
[    1.180000] LR is at gpmi_nand_probe+0x42c/0x894
[    1.180000] pc : [&lt;c025fcb0&gt;]    lr : [&lt;c02f6a68&gt;]    psr: 20000053
[    1.180000] sp : c743be2c  ip : 600000d3  fp : ffffffff
[    1.180000] r10: 000005d0  r9 : c02f5f08  r8 : 00000000
[    1.180000] r7 : c75858a8  r6 : c75858a8  r5 : c7585b18  r4 : c7585800
[    1.180000] r3 : 000005d0  r2 : 00000004  r1 : c05c33e4  r0 : 000005d0
[    1.180000] Flags: nzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
[    1.180000] Control: 0005317f  Table: 40004000  DAC: 00000017
[    1.180000] Process swapper (pid: 1, stack limit = 0xc743a1c0)
--------------------------------------------------------------------

This patch rearrange the init procedure:
   Set the NAND_SKIP_BBTSCAN to skip the nand scan firstly, and after we
   set the proper settings, we will call the chip-&gt;scan_bbt() manually.

Signed-off-by: Huang Shijie &lt;b32955@freescale.com&gt;
Reported-by: Fabio Estevam &lt;festevam@gmail.com&gt;
Tested-by: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: gpmi: fix kernel BUG due to racing DMA operations</title>
<updated>2013-12-04T19:05:25+00:00</updated>
<author>
<name>Huang Shijie</name>
<email>b32955@freescale.com</email>
</author>
<published>2013-11-11T04:13:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=559687590db4a3de6c63280914f2a3e3dcc7a478'/>
<id>559687590db4a3de6c63280914f2a3e3dcc7a478</id>
<content type='text'>
commit 7b3d2fb92067bcb29f0f085a9fa9fa64920a6646 upstream.

[1] The gpmi uses the nand_command_lp to issue the commands to NAND chips.
    The gpmi issues a DMA operation with gpmi_cmd_ctrl when it handles
    a NAND_CMD_NONE control command. So when we read a page(NAND_CMD_READ0)
    from the NAND, we may send two DMA operations back-to-back.

    If we do not serialize the two DMA operations, we will meet a bug when

    1.1) we enable CONFIG_DMA_API_DEBUG, CONFIG_DMADEVICES_DEBUG,
         and CONFIG_DEBUG_SG.

    1.2) Use the following commands in an UART console and a SSH console:
         cmd 1: while true;do dd if=/dev/mtd0 of=/dev/null;done
         cmd 1: while true;do dd if=/dev/mmcblk0 of=/dev/null;done

    The kernel log shows below:
    -----------------------------------------------------------------
    kernel BUG at lib/scatterlist.c:28!
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
      .........................
    [&lt;80044a0c&gt;] (__bug+0x18/0x24) from [&lt;80249b74&gt;] (sg_next+0x48/0x4c)
    [&lt;80249b74&gt;] (sg_next+0x48/0x4c) from [&lt;80255398&gt;] (debug_dma_unmap_sg+0x170/0x1a4)
    [&lt;80255398&gt;] (debug_dma_unmap_sg+0x170/0x1a4) from [&lt;8004af58&gt;] (dma_unmap_sg+0x14/0x6c)
    [&lt;8004af58&gt;] (dma_unmap_sg+0x14/0x6c) from [&lt;8027e594&gt;] (mxs_dma_tasklet+0x18/0x1c)
    [&lt;8027e594&gt;] (mxs_dma_tasklet+0x18/0x1c) from [&lt;8007d444&gt;] (tasklet_action+0x114/0x164)
    -----------------------------------------------------------------

    1.3) Assume the two DMA operations is X (first) and Y (second).

         The root cause of the bug:
	   Assume process P issues DMA X, and sleep on the completion
	 @this-&gt;dma_done. X's tasklet callback is dma_irq_callback. It firstly
	 wake up the process sleeping on the completion @this-&gt;dma_done,
	 and then trid to unmap the scatterlist S. The waked process P will
	 issue Y in another ARM core. Y initializes S-&gt;sg_magic to zero
	 with sg_init_one(), while dma_irq_callback is unmapping S at the same
	 time.

	 See the diagram:

                   ARM core 0              |         ARM core 1
	 -------------------------------------------------------------
         (P issues DMA X, then sleep)  --&gt; |
                                           |
         (X's tasklet wakes P)         --&gt; |
                                           |
                                           | &lt;-- (P begin to issue DMA Y)
                                           |
         (X's tasklet unmap the            |
      scatterlist S with dma_unmap_sg) --&gt; | &lt;-- (Y calls sg_init_one() to init
                                           |      scatterlist S)
                                           |

[2] This patch serialize both the X and Y in the following way:
     Unmap the DMA scatterlist S firstly, and wake up the process at the end
     of the DMA callback, in such a way, Y will be executed after X.

     After this patch:

                   ARM core 0              |         ARM core 1
	 -------------------------------------------------------------
         (P issues DMA X, then sleep)  --&gt; |
                                           |
         (X's tasklet unmap the            |
      scatterlist S with dma_unmap_sg) --&gt; |
                                           |
         (X's tasklet wakes P)         --&gt; |
                                           |
                                           | &lt;-- (P begin to issue DMA Y)
                                           |
                                           | &lt;-- (Y calls sg_init_one() to init
                                           |     scatterlist S)
                                           |

Signed-off-by: Huang Shijie &lt;b32955@freescale.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
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 7b3d2fb92067bcb29f0f085a9fa9fa64920a6646 upstream.

[1] The gpmi uses the nand_command_lp to issue the commands to NAND chips.
    The gpmi issues a DMA operation with gpmi_cmd_ctrl when it handles
    a NAND_CMD_NONE control command. So when we read a page(NAND_CMD_READ0)
    from the NAND, we may send two DMA operations back-to-back.

    If we do not serialize the two DMA operations, we will meet a bug when

    1.1) we enable CONFIG_DMA_API_DEBUG, CONFIG_DMADEVICES_DEBUG,
         and CONFIG_DEBUG_SG.

    1.2) Use the following commands in an UART console and a SSH console:
         cmd 1: while true;do dd if=/dev/mtd0 of=/dev/null;done
         cmd 1: while true;do dd if=/dev/mmcblk0 of=/dev/null;done

    The kernel log shows below:
    -----------------------------------------------------------------
    kernel BUG at lib/scatterlist.c:28!
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
      .........................
    [&lt;80044a0c&gt;] (__bug+0x18/0x24) from [&lt;80249b74&gt;] (sg_next+0x48/0x4c)
    [&lt;80249b74&gt;] (sg_next+0x48/0x4c) from [&lt;80255398&gt;] (debug_dma_unmap_sg+0x170/0x1a4)
    [&lt;80255398&gt;] (debug_dma_unmap_sg+0x170/0x1a4) from [&lt;8004af58&gt;] (dma_unmap_sg+0x14/0x6c)
    [&lt;8004af58&gt;] (dma_unmap_sg+0x14/0x6c) from [&lt;8027e594&gt;] (mxs_dma_tasklet+0x18/0x1c)
    [&lt;8027e594&gt;] (mxs_dma_tasklet+0x18/0x1c) from [&lt;8007d444&gt;] (tasklet_action+0x114/0x164)
    -----------------------------------------------------------------

    1.3) Assume the two DMA operations is X (first) and Y (second).

         The root cause of the bug:
	   Assume process P issues DMA X, and sleep on the completion
	 @this-&gt;dma_done. X's tasklet callback is dma_irq_callback. It firstly
	 wake up the process sleeping on the completion @this-&gt;dma_done,
	 and then trid to unmap the scatterlist S. The waked process P will
	 issue Y in another ARM core. Y initializes S-&gt;sg_magic to zero
	 with sg_init_one(), while dma_irq_callback is unmapping S at the same
	 time.

	 See the diagram:

                   ARM core 0              |         ARM core 1
	 -------------------------------------------------------------
         (P issues DMA X, then sleep)  --&gt; |
                                           |
         (X's tasklet wakes P)         --&gt; |
                                           |
                                           | &lt;-- (P begin to issue DMA Y)
                                           |
         (X's tasklet unmap the            |
      scatterlist S with dma_unmap_sg) --&gt; | &lt;-- (Y calls sg_init_one() to init
                                           |      scatterlist S)
                                           |

[2] This patch serialize both the X and Y in the following way:
     Unmap the DMA scatterlist S firstly, and wake up the process at the end
     of the DMA callback, in such a way, Y will be executed after X.

     After this patch:

                   ARM core 0              |         ARM core 1
	 -------------------------------------------------------------
         (P issues DMA X, then sleep)  --&gt; |
                                           |
         (X's tasklet unmap the            |
      scatterlist S with dma_unmap_sg) --&gt; |
                                           |
         (X's tasklet wakes P)         --&gt; |
                                           |
                                           | &lt;-- (P begin to issue DMA Y)
                                           |
                                           | &lt;-- (Y calls sg_init_one() to init
                                           |     scatterlist S)
                                           |

Signed-off-by: Huang Shijie &lt;b32955@freescale.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: atmel_nand: fix bug driver will in a dead lock if no nand detected</title>
<updated>2013-12-04T19:05:25+00:00</updated>
<author>
<name>Josh Wu</name>
<email>josh.wu@atmel.com</email>
</author>
<published>2013-11-05T09:59:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8a631f3a6a650c3445b4463913e9aca50aafdde6'/>
<id>8a631f3a6a650c3445b4463913e9aca50aafdde6</id>
<content type='text'>
commit a749d13acd8e079ed4c77a9456d842dc94af8f17 upstream.

In the atmel driver probe function, the code shows like following:
  atmel_nand_probe(...) {
        ...

  err_nand_ioremap:
        platform_driver_unregister(&amp;atmel_nand_nfc_driver);
        return res;
  }

If no nand flash detected, the driver probe function will goto
err_nand_ioremap label.
Then platform_driver_unregister() will be called. It will get the
lock of atmel_nand device since it is parent of nfc_device. The
problem is the lock is already hold by atmel_nand_probe itself.
So system will be in a dead lock.

This patch just simply removed to platform_driver_unregister() call.
When atmel_nand driver is quit the platform_driver_unregister() will
be called in atmel_nand_remove().

[Brian: the NAND platform probe really has no business
 registering/unregistering another driver; this fixes the deadlock, but
 we should follow up the likely racy behavior here with a better
 architecture]

Signed-off-by: Josh Wu &lt;josh.wu@atmel.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
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 a749d13acd8e079ed4c77a9456d842dc94af8f17 upstream.

In the atmel driver probe function, the code shows like following:
  atmel_nand_probe(...) {
        ...

  err_nand_ioremap:
        platform_driver_unregister(&amp;atmel_nand_nfc_driver);
        return res;
  }

If no nand flash detected, the driver probe function will goto
err_nand_ioremap label.
Then platform_driver_unregister() will be called. It will get the
lock of atmel_nand device since it is parent of nfc_device. The
problem is the lock is already hold by atmel_nand_probe itself.
So system will be in a dead lock.

This patch just simply removed to platform_driver_unregister() call.
When atmel_nand driver is quit the platform_driver_unregister() will
be called in atmel_nand_remove().

[Brian: the NAND platform probe really has no business
 registering/unregistering another driver; this fixes the deadlock, but
 we should follow up the likely racy behavior here with a better
 architecture]

Signed-off-by: Josh Wu &lt;josh.wu@atmel.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: m25p80: fix allocation size</title>
<updated>2013-12-04T19:05:24+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2013-07-25T01:32:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0e2155bedf934f446edf64ffc3c21f09b61d6b4d'/>
<id>0e2155bedf934f446edf64ffc3c21f09b61d6b4d</id>
<content type='text'>
commit 778d226a1462572b51d6777cdb1d611543410cb4 upstream.

This patch fixes two memory errors:

1. During a probe failure (in mtd_device_parse_register?) the command
   buffer would not be freed.

2. The command buffer's size is determined based on the 'fast_read'
   boolean, but the assignment of fast_read is made after this
   allocation. Thus, the buffer may be allocated "too small".

To fix the first, just switch to the devres version of kzalloc.

To fix the second, increase MAX_CMD_SIZE unconditionally. It's not worth
saving a byte to fiddle around with the conditions here.

This problem was reported by Yuhang Wang a while back.

Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Reported-by: Yuhang Wang &lt;wangyuhang2014@gmail.com&gt;
Reviewed-by: Sourav Poddar &lt;sourav.poddar@ti.com&gt;
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 778d226a1462572b51d6777cdb1d611543410cb4 upstream.

This patch fixes two memory errors:

1. During a probe failure (in mtd_device_parse_register?) the command
   buffer would not be freed.

2. The command buffer's size is determined based on the 'fast_read'
   boolean, but the assignment of fast_read is made after this
   allocation. Thus, the buffer may be allocated "too small".

To fix the first, just switch to the devres version of kzalloc.

To fix the second, increase MAX_CMD_SIZE unconditionally. It's not worth
saving a byte to fiddle around with the conditions here.

This problem was reported by Yuhang Wang a while back.

Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Reported-by: Yuhang Wang &lt;wangyuhang2014@gmail.com&gt;
Reviewed-by: Sourav Poddar &lt;sourav.poddar@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: nand: hack ONFI for non-power-of-2 dimensions</title>
<updated>2013-12-04T19:05:24+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2013-08-28T01:45:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=87ce636f07aa77f000a6b8bc4b7449d7879b3005'/>
<id>87ce636f07aa77f000a6b8bc4b7449d7879b3005</id>
<content type='text'>
commit 4355b70cf48363c50a9de450b01178c83aba8f6a upstream.

Some bright specification writers decided to write this in the ONFI spec
(from ONFI 3.0, Section 3.1):

  "The number of blocks and number of pages per block is not required to
  be a power of two. In the case where one of these values is not a
  power of two, the corresponding address shall be rounded to an
  integral number of bits such that it addresses a range up to the
  subsequent power of two value. The host shall not access upper
  addresses in a range that is shown as not supported."

This breaks every assumption MTD makes about NAND block/chip-size
dimensions -- they *must* be a power of two!

And of course, an enterprising manufacturer has made use of this lovely
freedom. Exhibit A: Micron MT29F32G08CBADAWP

  "- Plane size: 2 planes x 1064 blocks per plane
   - Device size: 32Gb: 2128 blockss [sic]"

This quickly hits a BUG() in nand_base.c, since the extra dimensions
overflow so we think it's a second chip (on my single-chip setup):

    ONFI param page 0 valid
    ONFI flash detected
    NAND device: Manufacturer ID: 0x2c, Chip ID: 0x44 (Micron MT29F32G08CBADAWP), 4256MiB, page size: 8192, OOB size: 744
    ------------[ cut here ]------------
    kernel BUG at drivers/mtd/nand/nand_base.c:203!
    Internal error: Oops - BUG: 0 [#1] SMP ARM
    [... trim ...]
    [&lt;c02cf3e4&gt;] (nand_select_chip+0x18/0x2c) from [&lt;c02d25c0&gt;] (nand_do_read_ops+0x90/0x424)
    [&lt;c02d25c0&gt;] (nand_do_read_ops+0x90/0x424) from [&lt;c02d2dd8&gt;] (nand_read+0x54/0x78)
    [&lt;c02d2dd8&gt;] (nand_read+0x54/0x78) from [&lt;c02ad2c8&gt;] (mtd_read+0x84/0xbc)
    [&lt;c02ad2c8&gt;] (mtd_read+0x84/0xbc) from [&lt;c02d4b28&gt;] (scan_read.clone.4+0x4c/0x64)
    [&lt;c02d4b28&gt;] (scan_read.clone.4+0x4c/0x64) from [&lt;c02d4c88&gt;] (search_bbt+0x148/0x290)
    [&lt;c02d4c88&gt;] (search_bbt+0x148/0x290) from [&lt;c02d4ea4&gt;] (nand_scan_bbt+0xd4/0x5c0)
    [... trim ...]
    ---[ end trace 0c9363860d865ff2 ]---

So to fix this, just truncate these dimensions down to the greatest
power-of-2 dimension that is less than or equal to the specified
dimension.

Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
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 4355b70cf48363c50a9de450b01178c83aba8f6a upstream.

Some bright specification writers decided to write this in the ONFI spec
(from ONFI 3.0, Section 3.1):

  "The number of blocks and number of pages per block is not required to
  be a power of two. In the case where one of these values is not a
  power of two, the corresponding address shall be rounded to an
  integral number of bits such that it addresses a range up to the
  subsequent power of two value. The host shall not access upper
  addresses in a range that is shown as not supported."

This breaks every assumption MTD makes about NAND block/chip-size
dimensions -- they *must* be a power of two!

And of course, an enterprising manufacturer has made use of this lovely
freedom. Exhibit A: Micron MT29F32G08CBADAWP

  "- Plane size: 2 planes x 1064 blocks per plane
   - Device size: 32Gb: 2128 blockss [sic]"

This quickly hits a BUG() in nand_base.c, since the extra dimensions
overflow so we think it's a second chip (on my single-chip setup):

    ONFI param page 0 valid
    ONFI flash detected
    NAND device: Manufacturer ID: 0x2c, Chip ID: 0x44 (Micron MT29F32G08CBADAWP), 4256MiB, page size: 8192, OOB size: 744
    ------------[ cut here ]------------
    kernel BUG at drivers/mtd/nand/nand_base.c:203!
    Internal error: Oops - BUG: 0 [#1] SMP ARM
    [... trim ...]
    [&lt;c02cf3e4&gt;] (nand_select_chip+0x18/0x2c) from [&lt;c02d25c0&gt;] (nand_do_read_ops+0x90/0x424)
    [&lt;c02d25c0&gt;] (nand_do_read_ops+0x90/0x424) from [&lt;c02d2dd8&gt;] (nand_read+0x54/0x78)
    [&lt;c02d2dd8&gt;] (nand_read+0x54/0x78) from [&lt;c02ad2c8&gt;] (mtd_read+0x84/0xbc)
    [&lt;c02ad2c8&gt;] (mtd_read+0x84/0xbc) from [&lt;c02d4b28&gt;] (scan_read.clone.4+0x4c/0x64)
    [&lt;c02d4b28&gt;] (scan_read.clone.4+0x4c/0x64) from [&lt;c02d4c88&gt;] (search_bbt+0x148/0x290)
    [&lt;c02d4c88&gt;] (search_bbt+0x148/0x290) from [&lt;c02d4ea4&gt;] (nand_scan_bbt+0xd4/0x5c0)
    [... trim ...]
    ---[ end trace 0c9363860d865ff2 ]---

So to fix this, just truncate these dimensions down to the greatest
power-of-2 dimension that is less than or equal to the specified
dimension.

Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
