<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mtd, branch v3.16.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: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc()</title>
<updated>2014-09-17T16:22:21+00:00</updated>
<author>
<name>Roger Quadros</name>
<email>rogerq@ti.com</email>
</author>
<published>2014-08-25T23:15:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=20c0fb35f167f18454c522a3c877da0247a3b0e0'/>
<id>20c0fb35f167f18454c522a3c877da0247a3b0e0</id>
<content type='text'>
commit 40ddbf5069bd4e11447c0088fc75318e0aac53f0 upstream.

commit 65b97cf6b8de introduced in v3.7 caused a regression
by using a reversed CS_MASK thus causing omap_calculate_ecc to
always fail. As the NAND base driver never checks for .calculate()'s
return value, the zeroed ECC values are used as is without showing
any error to the user. However, this won't work and the NAND device
won't be guarded by any error code.

Fix the issue by using the correct mask.

Code was tested on omap3beagle using the following procedure
- flash the primary bootloader (MLO) from the kernel to the first
NAND partition using nandwrite.
- boot the board from NAND. This utilizes OMAP ROM loader that
relies on 1-bit Hamming code ECC.

Fixes: 65b97cf6b8de (mtd: nand: omap2: handle nand on gpmc)

Signed-off-by: Roger Quadros &lt;rogerq@ti.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.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 40ddbf5069bd4e11447c0088fc75318e0aac53f0 upstream.

commit 65b97cf6b8de introduced in v3.7 caused a regression
by using a reversed CS_MASK thus causing omap_calculate_ecc to
always fail. As the NAND base driver never checks for .calculate()'s
return value, the zeroed ECC values are used as is without showing
any error to the user. However, this won't work and the NAND device
won't be guarded by any error code.

Fix the issue by using the correct mask.

Code was tested on omap3beagle using the following procedure
- flash the primary bootloader (MLO) from the kernel to the first
NAND partition using nandwrite.
- boot the board from NAND. This utilizes OMAP ROM loader that
relies on 1-bit Hamming code ECC.

Fixes: 65b97cf6b8de (mtd: nand: omap2: handle nand on gpmc)

Signed-off-by: Roger Quadros &lt;rogerq@ti.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mtd/ftl: fix the double free of the buffers allocated in build_maps()</title>
<updated>2014-09-17T16:22:20+00:00</updated>
<author>
<name>Kevin Hao</name>
<email>haokexin@gmail.com</email>
</author>
<published>2014-07-03T02:35:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=711f8bcf1dd5608d2a841f7e1bb471090e53514f'/>
<id>711f8bcf1dd5608d2a841f7e1bb471090e53514f</id>
<content type='text'>
commit a152056c912db82860a8b4c23d0bd3a5aa89e363 upstream.

I got the following panic on my fsl p5020ds board.

  Unable to handle kernel paging request for data at address 0x7375627379737465
  Faulting instruction address: 0xc000000000100778
  Oops: Kernel access of bad area, sig: 11 [#1]
  SMP NR_CPUS=24 CoreNet Generic
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-next-20140613 #145
  task: c0000000fe080000 ti: c0000000fe088000 task.ti: c0000000fe088000
  NIP: c000000000100778 LR: c00000000010073c CTR: 0000000000000000
  REGS: c0000000fe08aa00 TRAP: 0300   Not tainted  (3.15.0-next-20140613)
  MSR: 0000000080029000 &lt;CE,EE,ME&gt;  CR: 24ad2e24  XER: 00000000
  DEAR: 7375627379737465 ESR: 0000000000000000 SOFTE: 1
  GPR00: c0000000000c99b0 c0000000fe08ac80 c0000000009598e0 c0000000fe001d80
  GPR04: 00000000000000d0 0000000000000913 c000000007902b20 0000000000000000
  GPR08: c0000000feaae888 0000000000000000 0000000007091000 0000000000200200
  GPR12: 0000000028ad2e28 c00000000fff4000 c0000000007abe08 0000000000000000
  GPR16: c0000000007ab160 c0000000007aaf98 c00000000060ba68 c0000000007abda8
  GPR20: c0000000007abde8 c0000000feaea6f8 c0000000feaea708 c0000000007abd10
  GPR24: c000000000989370 c0000000008c6228 00000000000041ed c0000000fe00a400
  GPR28: c00000000017c1cc 00000000000000d0 7375627379737465 c0000000fe001d80
  NIP [c000000000100778] .__kmalloc_track_caller+0x70/0x168
  LR [c00000000010073c] .__kmalloc_track_caller+0x34/0x168
  Call Trace:
  [c0000000fe08ac80] [c00000000087e6b8] uevent_sock_list+0x0/0x10 (unreliable)
  [c0000000fe08ad20] [c0000000000c99b0] .kstrdup+0x44/0x90
  [c0000000fe08adc0] [c00000000017c1cc] .__kernfs_new_node+0x4c/0x130
  [c0000000fe08ae70] [c00000000017d7e4] .kernfs_new_node+0x2c/0x64
  [c0000000fe08aef0] [c00000000017db00] .kernfs_create_dir_ns+0x34/0xc8
  [c0000000fe08af80] [c00000000018067c] .sysfs_create_dir_ns+0x58/0xcc
  [c0000000fe08b010] [c0000000002c711c] .kobject_add_internal+0xc8/0x384
  [c0000000fe08b0b0] [c0000000002c7644] .kobject_add+0x64/0xc8
  [c0000000fe08b140] [c000000000355ebc] .device_add+0x11c/0x654
  [c0000000fe08b200] [c0000000002b5988] .add_disk+0x20c/0x4b4
  [c0000000fe08b2c0] [c0000000003a21d4] .add_mtd_blktrans_dev+0x340/0x514
  [c0000000fe08b350] [c0000000003a3410] .mtdblock_add_mtd+0x74/0xb4
  [c0000000fe08b3e0] [c0000000003a32cc] .blktrans_notify_add+0x64/0x94
  [c0000000fe08b470] [c00000000039b5b4] .add_mtd_device+0x1d4/0x368
  [c0000000fe08b520] [c00000000039b830] .mtd_device_parse_register+0xe8/0x104
  [c0000000fe08b5c0] [c0000000003b8408] .of_flash_probe+0x72c/0x734
  [c0000000fe08b750] [c00000000035ba40] .platform_drv_probe+0x38/0x84
  [c0000000fe08b7d0] [c0000000003599a4] .really_probe+0xa4/0x29c
  [c0000000fe08b870] [c000000000359d3c] .__driver_attach+0x100/0x104
  [c0000000fe08b900] [c00000000035746c] .bus_for_each_dev+0x84/0xe4
  [c0000000fe08b9a0] [c0000000003593c0] .driver_attach+0x24/0x38
  [c0000000fe08ba10] [c000000000358f24] .bus_add_driver+0x1c8/0x2ac
  [c0000000fe08bab0] [c00000000035a3a4] .driver_register+0x8c/0x158
  [c0000000fe08bb30] [c00000000035b9f4] .__platform_driver_register+0x6c/0x80
  [c0000000fe08bba0] [c00000000084e080] .of_flash_driver_init+0x1c/0x30
  [c0000000fe08bc10] [c000000000001864] .do_one_initcall+0xbc/0x238
  [c0000000fe08bd00] [c00000000082cdc0] .kernel_init_freeable+0x188/0x268
  [c0000000fe08bdb0] [c0000000000020a0] .kernel_init+0x1c/0xf7c
  [c0000000fe08be30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4
  Instruction dump:
  41bd0010 480000c8 4bf04eb5 60000000 e94d0028 e93f0000 7cc95214 e8a60008
  7fc9502a 2fbe0000 419e00c8 e93f0022 &lt;7f7e482a&gt; 39200000 88ed06b2 992d06b2
  ---[ end trace b4c9a94804a42d40 ]---

It seems that the corrupted partition header on my mtd device triggers
a bug in the ftl. In function build_maps() it will allocate the buffers
needed by the mtd partition, but if something goes wrong such as kmalloc
failure, mtd read error or invalid partition header parameter, it will
free all allocated buffers and then return non-zero. In my case, it
seems that partition header parameter 'NumTransferUnits' is invalid.

And the ftl_freepart() is a function which free all the partition
buffers allocated by build_maps(). Given the build_maps() is a self
cleaning function, so there is no need to invoke this function even
if build_maps() return with error. Otherwise it will causes the
buffers to be freed twice and then weird things would happen.

Signed-off-by: Kevin Hao &lt;haokexin@gmail.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 a152056c912db82860a8b4c23d0bd3a5aa89e363 upstream.

I got the following panic on my fsl p5020ds board.

  Unable to handle kernel paging request for data at address 0x7375627379737465
  Faulting instruction address: 0xc000000000100778
  Oops: Kernel access of bad area, sig: 11 [#1]
  SMP NR_CPUS=24 CoreNet Generic
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-next-20140613 #145
  task: c0000000fe080000 ti: c0000000fe088000 task.ti: c0000000fe088000
  NIP: c000000000100778 LR: c00000000010073c CTR: 0000000000000000
  REGS: c0000000fe08aa00 TRAP: 0300   Not tainted  (3.15.0-next-20140613)
  MSR: 0000000080029000 &lt;CE,EE,ME&gt;  CR: 24ad2e24  XER: 00000000
  DEAR: 7375627379737465 ESR: 0000000000000000 SOFTE: 1
  GPR00: c0000000000c99b0 c0000000fe08ac80 c0000000009598e0 c0000000fe001d80
  GPR04: 00000000000000d0 0000000000000913 c000000007902b20 0000000000000000
  GPR08: c0000000feaae888 0000000000000000 0000000007091000 0000000000200200
  GPR12: 0000000028ad2e28 c00000000fff4000 c0000000007abe08 0000000000000000
  GPR16: c0000000007ab160 c0000000007aaf98 c00000000060ba68 c0000000007abda8
  GPR20: c0000000007abde8 c0000000feaea6f8 c0000000feaea708 c0000000007abd10
  GPR24: c000000000989370 c0000000008c6228 00000000000041ed c0000000fe00a400
  GPR28: c00000000017c1cc 00000000000000d0 7375627379737465 c0000000fe001d80
  NIP [c000000000100778] .__kmalloc_track_caller+0x70/0x168
  LR [c00000000010073c] .__kmalloc_track_caller+0x34/0x168
  Call Trace:
  [c0000000fe08ac80] [c00000000087e6b8] uevent_sock_list+0x0/0x10 (unreliable)
  [c0000000fe08ad20] [c0000000000c99b0] .kstrdup+0x44/0x90
  [c0000000fe08adc0] [c00000000017c1cc] .__kernfs_new_node+0x4c/0x130
  [c0000000fe08ae70] [c00000000017d7e4] .kernfs_new_node+0x2c/0x64
  [c0000000fe08aef0] [c00000000017db00] .kernfs_create_dir_ns+0x34/0xc8
  [c0000000fe08af80] [c00000000018067c] .sysfs_create_dir_ns+0x58/0xcc
  [c0000000fe08b010] [c0000000002c711c] .kobject_add_internal+0xc8/0x384
  [c0000000fe08b0b0] [c0000000002c7644] .kobject_add+0x64/0xc8
  [c0000000fe08b140] [c000000000355ebc] .device_add+0x11c/0x654
  [c0000000fe08b200] [c0000000002b5988] .add_disk+0x20c/0x4b4
  [c0000000fe08b2c0] [c0000000003a21d4] .add_mtd_blktrans_dev+0x340/0x514
  [c0000000fe08b350] [c0000000003a3410] .mtdblock_add_mtd+0x74/0xb4
  [c0000000fe08b3e0] [c0000000003a32cc] .blktrans_notify_add+0x64/0x94
  [c0000000fe08b470] [c00000000039b5b4] .add_mtd_device+0x1d4/0x368
  [c0000000fe08b520] [c00000000039b830] .mtd_device_parse_register+0xe8/0x104
  [c0000000fe08b5c0] [c0000000003b8408] .of_flash_probe+0x72c/0x734
  [c0000000fe08b750] [c00000000035ba40] .platform_drv_probe+0x38/0x84
  [c0000000fe08b7d0] [c0000000003599a4] .really_probe+0xa4/0x29c
  [c0000000fe08b870] [c000000000359d3c] .__driver_attach+0x100/0x104
  [c0000000fe08b900] [c00000000035746c] .bus_for_each_dev+0x84/0xe4
  [c0000000fe08b9a0] [c0000000003593c0] .driver_attach+0x24/0x38
  [c0000000fe08ba10] [c000000000358f24] .bus_add_driver+0x1c8/0x2ac
  [c0000000fe08bab0] [c00000000035a3a4] .driver_register+0x8c/0x158
  [c0000000fe08bb30] [c00000000035b9f4] .__platform_driver_register+0x6c/0x80
  [c0000000fe08bba0] [c00000000084e080] .of_flash_driver_init+0x1c/0x30
  [c0000000fe08bc10] [c000000000001864] .do_one_initcall+0xbc/0x238
  [c0000000fe08bd00] [c00000000082cdc0] .kernel_init_freeable+0x188/0x268
  [c0000000fe08bdb0] [c0000000000020a0] .kernel_init+0x1c/0xf7c
  [c0000000fe08be30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4
  Instruction dump:
  41bd0010 480000c8 4bf04eb5 60000000 e94d0028 e93f0000 7cc95214 e8a60008
  7fc9502a 2fbe0000 419e00c8 e93f0022 &lt;7f7e482a&gt; 39200000 88ed06b2 992d06b2
  ---[ end trace b4c9a94804a42d40 ]---

It seems that the corrupted partition header on my mtd device triggers
a bug in the ftl. In function build_maps() it will allocate the buffers
needed by the mtd partition, but if something goes wrong such as kmalloc
failure, mtd read error or invalid partition header parameter, it will
free all allocated buffers and then return non-zero. In my case, it
seems that partition header parameter 'NumTransferUnits' is invalid.

And the ftl_freepart() is a function which free all the partition
buffers allocated by build_maps(). Given the build_maps() is a self
cleaning function, so there is no need to invoke this function even
if build_maps() return with error. Otherwise it will causes the
buffers to be freed twice and then weird things would happen.

Signed-off-by: Kevin Hao &lt;haokexin@gmail.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>Merge tag 'upstream-3.16-rc6' of git://git.infradead.org/linux-ubifs</title>
<updated>2014-07-18T16:23:34+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-07-18T16:23:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=033ead8230c2cf9cdc2d6e1148bfdf5674012a9c'/>
<id>033ead8230c2cf9cdc2d6e1148bfdf5674012a9c</id>
<content type='text'>
Pull UBI fixes from Artem Bityutskiy:
 "Two UBI fastmap-related fixes for v3.16:

   - fix UBI fastmap support which we broke in 3.16-rc1 by reversing the
     volumes RB-tree sorting criteria.
   - make sure that we scrub all PEBs where we see bit-flips - we were
     missing some of them when the fastmap feature was enabled"

* tag 'upstream-3.16-rc6' of git://git.infradead.org/linux-ubifs:
  UBI: fastmap: do not miss bit-flips
  UBI: fix the volumes tree sorting criteria
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull UBI fixes from Artem Bityutskiy:
 "Two UBI fastmap-related fixes for v3.16:

   - fix UBI fastmap support which we broke in 3.16-rc1 by reversing the
     volumes RB-tree sorting criteria.
   - make sure that we scrub all PEBs where we see bit-flips - we were
     missing some of them when the fastmap feature was enabled"

* tag 'upstream-3.16-rc6' of git://git.infradead.org/linux-ubifs:
  UBI: fastmap: do not miss bit-flips
  UBI: fix the volumes tree sorting criteria
</pre>
</div>
</content>
</entry>
<entry>
<title>UBI: fastmap: do not miss bit-flips</title>
<updated>2014-07-16T05:32:00+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2014-05-21T05:35:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=44305ebde243a7cce2c592cc89afe5041d8bf884'/>
<id>44305ebde243a7cce2c592cc89afe5041d8bf884</id>
<content type='text'>
The return value from 'ubi_io_read_ec_hdr()' was stored in 'err', not in 'ret'.
This fix makes sure Fastmap-enabled UBI does not miss bit-flip while reading EC
headers, events and scrubs the affected PEBs.

This issue was reported by Coverity Scan.

Artem: improved the commit message.

Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Acked-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The return value from 'ubi_io_read_ec_hdr()' was stored in 'err', not in 'ret'.
This fix makes sure Fastmap-enabled UBI does not miss bit-flip while reading EC
headers, events and scrubs the affected PEBs.

This issue was reported by Coverity Scan.

Artem: improved the commit message.

Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Acked-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: cfi_cmdset_0001.c: add support for Sharp LH28F640BF NOR</title>
<updated>2014-07-14T05:22:47+00:00</updated>
<author>
<name>Andrea Adami</name>
<email>andrea.adami@gmail.com</email>
</author>
<published>2014-06-02T21:38:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=812c5fa82bae9f377f49000d7636c19a8b61735c'/>
<id>812c5fa82bae9f377f49000d7636c19a8b61735c</id>
<content type='text'>
This family of chips was long ago supported by the pre-cfi driver.
CFI code tested on several Zaurus SL-5500 (Collie) 2x16 on 32 bit bus.

Function is_LH28F640BF() mimics is_m29ew() from cmdset_0002.c

Buffer write fixes as seen in 2007 patch c/o
Anti Sullin &lt;anti.sullin &lt;at&gt; artecdesign.ee&gt;
http://comments.gmane.org/gmane.linux.ports.arm.kernel/36733

[Brian: this patch is semi-urgent, because the following patch switches
  to using CFI detection for a chip which (until now) is unsupported by
  the CFI driver

  9218310  ARM: 8084/1: sa1100: collie: revert back to cfi_probe
]

Signed-off-by: Andrea Adami &lt;andrea.adami@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This family of chips was long ago supported by the pre-cfi driver.
CFI code tested on several Zaurus SL-5500 (Collie) 2x16 on 32 bit bus.

Function is_LH28F640BF() mimics is_m29ew() from cmdset_0002.c

Buffer write fixes as seen in 2007 patch c/o
Anti Sullin &lt;anti.sullin &lt;at&gt; artecdesign.ee&gt;
http://comments.gmane.org/gmane.linux.ports.arm.kernel/36733

[Brian: this patch is semi-urgent, because the following patch switches
  to using CFI detection for a chip which (until now) is unsupported by
  the CFI driver

  9218310  ARM: 8084/1: sa1100: collie: revert back to cfi_probe
]

Signed-off-by: Andrea Adami &lt;andrea.adami@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: nand: reduce the warning noise when the ECC is too weak</title>
<updated>2014-07-14T05:19:02+00:00</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2014-07-02T13:16:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=54c39e9ba3a93e3848ad8f9d082c39010cfc5e73'/>
<id>54c39e9ba3a93e3848ad8f9d082c39010cfc5e73</id>
<content type='text'>
In commit 67a9ad9b8a6f ("mtd: nand: Warn the user if the selected ECC
strength is too weak"), a check was added to inform the user when the
ECC used for a NAND device is weaker than the recommended ECC
advertised by the NAND chip. However, the warning uses WARN_ON(),
which has two undesirable side-effects:

 - It just prints to the kernel log the fact that there is a warning
   in this file, at this line, but it doesn't explain anything about
   the warning itself.

 - It dumps a stack trace which is very noisy, for something that the
   user is most likely not able to fix. If a certain ECC used by the
   kernel is weaker than the advertised one, it's most likely to make
   sure the kernel uses an ECC that is compatible with the one used by
   the bootloader, and changing the bootloader may not necessarily be
   easy. Therefore, normal users would not be able to do anything to
   fix this very noisy warning, and will have to suffer from it at
   every kernel boot. At least every time I see this stack trace in my
   kernel boot log, I wonder what new thing is broken, just to realize
   that it's once again this NAND ECC warning.

Therefore, this commit turns:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/thomas/projets/linux-2.6/drivers/mtd/nand/nand_base.c:4051 nand_scan_tail+0x538/0x780()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0-rc3-dirty #4
[&lt;c000e3dc&gt;] (unwind_backtrace) from [&lt;c000bee4&gt;] (show_stack+0x10/0x14)
[&lt;c000bee4&gt;] (show_stack) from [&lt;c0018180&gt;] (warn_slowpath_common+0x6c/0x8c)
[&lt;c0018180&gt;] (warn_slowpath_common) from [&lt;c001823c&gt;] (warn_slowpath_null+0x1c/0x24)
[&lt;c001823c&gt;] (warn_slowpath_null) from [&lt;c02c50cc&gt;] (nand_scan_tail+0x538/0x780)
[&lt;c02c50cc&gt;] (nand_scan_tail) from [&lt;c0639f78&gt;] (orion_nand_probe+0x224/0x2e4)
[&lt;c0639f78&gt;] (orion_nand_probe) from [&lt;c026da00&gt;] (platform_drv_probe+0x18/0x4c)
[&lt;c026da00&gt;] (platform_drv_probe) from [&lt;c026c1f4&gt;] (really_probe+0x80/0x218)
[&lt;c026c1f4&gt;] (really_probe) from [&lt;c026c47c&gt;] (__driver_attach+0x98/0x9c)
[&lt;c026c47c&gt;] (__driver_attach) from [&lt;c026a8f0&gt;] (bus_for_each_dev+0x64/0x94)
[&lt;c026a8f0&gt;] (bus_for_each_dev) from [&lt;c026bae4&gt;] (bus_add_driver+0x144/0x1ec)
[&lt;c026bae4&gt;] (bus_add_driver) from [&lt;c026cb00&gt;] (driver_register+0x78/0xf8)
[&lt;c026cb00&gt;] (driver_register) from [&lt;c026da5c&gt;] (platform_driver_probe+0x20/0xb8)
[&lt;c026da5c&gt;] (platform_driver_probe) from [&lt;c00088b8&gt;] (do_one_initcall+0x80/0x1d8)
[&lt;c00088b8&gt;] (do_one_initcall) from [&lt;c0620c9c&gt;] (kernel_init_freeable+0xf4/0x1b4)
[&lt;c0620c9c&gt;] (kernel_init_freeable) from [&lt;c049a098&gt;] (kernel_init+0x8/0xec)
[&lt;c049a098&gt;] (kernel_init) from [&lt;c00095f0&gt;] (ret_from_fork+0x14/0x24)
---[ end trace 62f87d875aceccb4 ]---

Into the much shorter, and much more useful:

nand: WARNING: MT29F2G08ABAEAWP: the ECC used on your system is too weak compared to the one required by the NAND chip

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In commit 67a9ad9b8a6f ("mtd: nand: Warn the user if the selected ECC
strength is too weak"), a check was added to inform the user when the
ECC used for a NAND device is weaker than the recommended ECC
advertised by the NAND chip. However, the warning uses WARN_ON(),
which has two undesirable side-effects:

 - It just prints to the kernel log the fact that there is a warning
   in this file, at this line, but it doesn't explain anything about
   the warning itself.

 - It dumps a stack trace which is very noisy, for something that the
   user is most likely not able to fix. If a certain ECC used by the
   kernel is weaker than the advertised one, it's most likely to make
   sure the kernel uses an ECC that is compatible with the one used by
   the bootloader, and changing the bootloader may not necessarily be
   easy. Therefore, normal users would not be able to do anything to
   fix this very noisy warning, and will have to suffer from it at
   every kernel boot. At least every time I see this stack trace in my
   kernel boot log, I wonder what new thing is broken, just to realize
   that it's once again this NAND ECC warning.

Therefore, this commit turns:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/thomas/projets/linux-2.6/drivers/mtd/nand/nand_base.c:4051 nand_scan_tail+0x538/0x780()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0-rc3-dirty #4
[&lt;c000e3dc&gt;] (unwind_backtrace) from [&lt;c000bee4&gt;] (show_stack+0x10/0x14)
[&lt;c000bee4&gt;] (show_stack) from [&lt;c0018180&gt;] (warn_slowpath_common+0x6c/0x8c)
[&lt;c0018180&gt;] (warn_slowpath_common) from [&lt;c001823c&gt;] (warn_slowpath_null+0x1c/0x24)
[&lt;c001823c&gt;] (warn_slowpath_null) from [&lt;c02c50cc&gt;] (nand_scan_tail+0x538/0x780)
[&lt;c02c50cc&gt;] (nand_scan_tail) from [&lt;c0639f78&gt;] (orion_nand_probe+0x224/0x2e4)
[&lt;c0639f78&gt;] (orion_nand_probe) from [&lt;c026da00&gt;] (platform_drv_probe+0x18/0x4c)
[&lt;c026da00&gt;] (platform_drv_probe) from [&lt;c026c1f4&gt;] (really_probe+0x80/0x218)
[&lt;c026c1f4&gt;] (really_probe) from [&lt;c026c47c&gt;] (__driver_attach+0x98/0x9c)
[&lt;c026c47c&gt;] (__driver_attach) from [&lt;c026a8f0&gt;] (bus_for_each_dev+0x64/0x94)
[&lt;c026a8f0&gt;] (bus_for_each_dev) from [&lt;c026bae4&gt;] (bus_add_driver+0x144/0x1ec)
[&lt;c026bae4&gt;] (bus_add_driver) from [&lt;c026cb00&gt;] (driver_register+0x78/0xf8)
[&lt;c026cb00&gt;] (driver_register) from [&lt;c026da5c&gt;] (platform_driver_probe+0x20/0xb8)
[&lt;c026da5c&gt;] (platform_driver_probe) from [&lt;c00088b8&gt;] (do_one_initcall+0x80/0x1d8)
[&lt;c00088b8&gt;] (do_one_initcall) from [&lt;c0620c9c&gt;] (kernel_init_freeable+0xf4/0x1b4)
[&lt;c0620c9c&gt;] (kernel_init_freeable) from [&lt;c049a098&gt;] (kernel_init+0x8/0xec)
[&lt;c049a098&gt;] (kernel_init) from [&lt;c00095f0&gt;] (ret_from_fork+0x14/0x24)
---[ end trace 62f87d875aceccb4 ]---

Into the much shorter, and much more useful:

nand: WARNING: MT29F2G08ABAEAWP: the ECC used on your system is too weak compared to the one required by the NAND chip

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: devices: elm: fix elm_context_save() and elm_context_restore() functions</title>
<updated>2014-07-05T22:44:42+00:00</updated>
<author>
<name>Ted Juan</name>
<email>ted.juan@gmail.com</email>
</author>
<published>2014-06-20T09:32:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6938ad40cb97a52d88a763008935340729a4acc7'/>
<id>6938ad40cb97a52d88a763008935340729a4acc7</id>
<content type='text'>
These two function's switch case lack the 'break' that make them always
return error.

Signed-off-by: Ted Juan &lt;ted.juan@gmail.com&gt;
Acked-by: Pekon Gupta &lt;pekon@ti.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.12.x+
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These two function's switch case lack the 'break' that make them always
return error.

Signed-off-by: Ted Juan &lt;ted.juan@gmail.com&gt;
Acked-by: Pekon Gupta &lt;pekon@ti.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.12.x+
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>UBI: fix the volumes tree sorting criteria</title>
<updated>2014-07-01T06:23:03+00:00</updated>
<author>
<name>Heiko Schocher</name>
<email>hs@denx.de</email>
</author>
<published>2014-06-24T07:25:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e9110361a9a4e258b072b14bd44eb78cf11453cb'/>
<id>e9110361a9a4e258b072b14bd44eb78cf11453cb</id>
<content type='text'>
Commig "604b592 UBI: fix rb_tree node comparison in add_map"
broke fastmap backward compatibility and older fastmap images
cannot be mounted anymore. The reason is that it changes the
volumes RB-tree sorting criteria. This patch fixes the problem.

Artem: re-write the commit message

Signed-off-by: Heiko Schocher &lt;hs@denx.de&gt;
Acked-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commig "604b592 UBI: fix rb_tree node comparison in add_map"
broke fastmap backward compatibility and older fastmap images
cannot be mounted anymore. The reason is that it changes the
volumes RB-tree sorting criteria. This patch fixes the problem.

Artem: re-write the commit message

Signed-off-by: Heiko Schocher &lt;hs@denx.de&gt;
Acked-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2014-06-12T17:30:18+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-06-12T17:30:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=16b9057804c02e2d351e9c8f606e909b43cbd9e7'/>
<id>16b9057804c02e2d351e9c8f606e909b43cbd9e7</id>
<content type='text'>
Pull vfs updates from Al Viro:
 "This the bunch that sat in -next + lock_parent() fix.  This is the
  minimal set; there's more pending stuff.

  In particular, I really hope to get acct.c fixes merged this cycle -
  we need that to deal sanely with delayed-mntput stuff.  In the next
  pile, hopefully - that series is fairly short and localized
  (kernel/acct.c, fs/super.c and fs/namespace.c).  In this pile: more
  iov_iter work.  Most of prereqs for -&gt;splice_write with sane locking
  order are there and Kent's dio rewrite would also fit nicely on top of
  this pile"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (70 commits)
  lock_parent: don't step on stale -&gt;d_parent of all-but-freed one
  kill generic_file_splice_write()
  ceph: switch to iter_file_splice_write()
  shmem: switch to iter_file_splice_write()
  nfs: switch to iter_splice_write_file()
  fs/splice.c: remove unneeded exports
  ocfs2: switch to iter_file_splice_write()
  -&gt;splice_write() via -&gt;write_iter()
  bio_vec-backed iov_iter
  optimize copy_page_{to,from}_iter()
  bury generic_file_aio_{read,write}
  lustre: get rid of messing with iovecs
  ceph: switch to -&gt;write_iter()
  ceph_sync_direct_write: stop poking into iov_iter guts
  ceph_sync_read: stop poking into iov_iter guts
  new helper: copy_page_from_iter()
  fuse: switch to -&gt;write_iter()
  btrfs: switch to -&gt;write_iter()
  ocfs2: switch to -&gt;write_iter()
  xfs: switch to -&gt;write_iter()
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull vfs updates from Al Viro:
 "This the bunch that sat in -next + lock_parent() fix.  This is the
  minimal set; there's more pending stuff.

  In particular, I really hope to get acct.c fixes merged this cycle -
  we need that to deal sanely with delayed-mntput stuff.  In the next
  pile, hopefully - that series is fairly short and localized
  (kernel/acct.c, fs/super.c and fs/namespace.c).  In this pile: more
  iov_iter work.  Most of prereqs for -&gt;splice_write with sane locking
  order are there and Kent's dio rewrite would also fit nicely on top of
  this pile"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (70 commits)
  lock_parent: don't step on stale -&gt;d_parent of all-but-freed one
  kill generic_file_splice_write()
  ceph: switch to iter_file_splice_write()
  shmem: switch to iter_file_splice_write()
  nfs: switch to iter_splice_write_file()
  fs/splice.c: remove unneeded exports
  ocfs2: switch to iter_file_splice_write()
  -&gt;splice_write() via -&gt;write_iter()
  bio_vec-backed iov_iter
  optimize copy_page_{to,from}_iter()
  bury generic_file_aio_{read,write}
  lustre: get rid of messing with iovecs
  ceph: switch to -&gt;write_iter()
  ceph_sync_direct_write: stop poking into iov_iter guts
  ceph_sync_read: stop poking into iov_iter guts
  new helper: copy_page_from_iter()
  fuse: switch to -&gt;write_iter()
  btrfs: switch to -&gt;write_iter()
  ocfs2: switch to -&gt;write_iter()
  xfs: switch to -&gt;write_iter()
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge commit '9f12600fe425bc28f0ccba034a77783c09c15af4' into for-linus</title>
<updated>2014-06-12T04:28:09+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2014-06-12T04:27:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9c1d5284c79fea050f115eadeec1dd1758e5c630'/>
<id>9c1d5284c79fea050f115eadeec1dd1758e5c630</id>
<content type='text'>
Backmerge of dcache.c changes from mainline.  It's that, or complete
rebase...

Conflicts:
	fs/splice.c

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Backmerge of dcache.c changes from mainline.  It's that, or complete
rebase...

Conflicts:
	fs/splice.c

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
