linux-stable.git/drivers/mtd, branch linux-3.17.y

mtd: m25p80: Fix module aliases for m25p80

2014-11-14T18:10:38+00:00

Based on a5b7616c55e188fe3d6ef686bef402d4703ecb62, but backported so
that a bunch of dependencies are not needed.

m25p80's device ID table is now spi_nor_ids, defined in spi-nor.  The
MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
its use was also removed at the same time.  Now if m25p80 is built as
a module it doesn't get the necessary aliases to be loaded
automatically.

A clean solution to this will involve defining the list of device
IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
API, but this is quite a large change.

As a quick fix suitable for stable, copy the device IDs back into
m25p80.

Fixes: 03e296f613af ("mtd: m25p80: use the SPI nor framework")
Signed-off-by: Ben Hutchings 
[Brian: backport without the dependencies]
Signed-off-by: Brian Norris 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0001.c: fix resume for LH28F640BF chips

2014-11-14T18:10:38+00:00

commit 89cf38dd536a7301d6b5f5ddd73f42074c01bfaa upstream.

After '#echo mem > /sys/power/state' some devices can not be properly resumed
because apparently the MTD Partition Configuration Register has been reset
to default thus the rootfs cannot be mounted cleanly on resume.
An example of this can be found in the SA-1100 Developer's Manual at 9.5.3.3
where the second step of the Sleep Shutdown Sequence is described:
"An internal reset is applied to the SA-1100. All units are reset...".

As workaround we refresh the PCR value as done initially on chip setup.

This behavior and the fix are confirmed by our tests done on 2 different Zaurus
collie units with kernel 3.17.

Fixes: 812c5fa82bae: ("mtd: cfi_cmdset_0001.c: add support for Sharp LH28F640BF NOR")
Signed-off-by: Dmitry Eremin-Solenikov 
Signed-off-by: Andrea Adami 
Signed-off-by: Brian Norris 
Signed-off-by: Greg Kroah-Hartman

UBI: add missing kmem_cache_free() in process_pool_aeb error path

2014-11-14T18:10:25+00:00

commit 1bf1890e86869032099b539bc83b098be12fc5a7 upstream.

I ran into this error after a ubiupdatevol, because I forgot to backport
e9110361a9a4 UBI: fix the volumes tree sorting criteria.

UBI error: process_pool_aeb: orphaned volume in fastmap pool
UBI error: ubi_scan_fastmap: Attach by fastmap failed, doing a full scan!
kmem_cache_destroy ubi_ainf_peb_slab: Slab cache still has objects
CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.18-00053-gf05cac8dbf85 #1
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (destroy_ai+0x230/0x244)
[] (destroy_ai) from [] (ubi_attach+0x98/0x1ec)
[] (ubi_attach) from [] (ubi_attach_mtd_dev+0x2b8/0x868)
[] (ubi_attach_mtd_dev) from [] (ubi_init+0x1dc/0x2ac)
[] (ubi_init) from [] (do_one_initcall+0x94/0x140)
[] (do_one_initcall) from [] (kernel_init_freeable+0xe8/0x1b0)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4)
[] (kernel_init) from [] (ret_from_fork+0x14/0x24)
UBI: scanning is finished

Freeing the cache in the error path fixes the Slab error.

Tested on at91sam9g35 (3.14.18+fastmap backports)

Signed-off-by: Richard Genoud 
Signed-off-by: Greg Kroah-Hartman

UBI: Dispatch update notification if the volume is updated

2014-11-14T18:10:25+00:00

commit fda322a1b3b9e8ee231913c500f73c6988b1aff5 upstream.

The UBI_IOCVOLUP ioctl is used to start an update and also to
truncate a volume. In the first case, a "volume updated" notification
is dispatched when the update is done.

This commit adds the "volume updated" notification to be also sent when
the volume is truncated. This is required for UBI block and gluebi to get
notified about the new volume size.

Signed-off-by: Ezequiel Garcia 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman

UBI: block: Add support for the UBI_VOLUME_UPDATED notification

2014-11-14T18:10:24+00:00

commit 06d9c2905f745c8b1920a335cbb366ba6b0fc754 upstream.

Static volumes can change its 'used_bytes' when they get updated,
and so the block interface must listen to the UBI_VOLUME_UPDATED
notification to resize the block device accordingly.

Signed-off-by: Ezequiel Garcia 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman

UBI: block: Fix block device size setting

2014-11-14T18:10:24+00:00

commit 978d6496758d19de2431ebf163337fc7b92f8c45 upstream.

We are currently taking the block device size from the ubi_volume_info.size
field. However, this is not the amount of data in the volume, but the
number of reserved physical eraseblocks, and hence leads to an incorrect
representation of the volume.

In particular, this produces I/O errors on static volumes as the block
interface may attempt to read unmapped PEBs:

$ cat /dev/ubiblock0_0 > /dev/null
UBI error: ubiblock_read_to_buf: ubiblock0_0 ubi_read error -22
end_request: I/O error, dev ubiblock0_0, sector 9536
Buffer I/O error on device ubiblock0_0, logical block 2384
[snip]

Fix this by using the ubi_volume_info.used_bytes field which is set to the
actual number of data bytes for both static and dynamic volumes.

While here, improve the error message to be less stupid and more useful:
UBI error: ubiblock_read_to_buf: ubiblock0_1 ubi_read error -9 on LEB=0, off=15872, len=512

It's worth noticing that the 512-byte sector representation of the volume
is only correct if the volume size is multiple of 512-bytes. This is true for
virtually any NAND device, given eraseblocks and pages are 512-byte multiple
and hence so is the LEB size.

Artem: tweak the error message and make it look more like other UBI error
messages.

Fixes: 9d54c8a33eec ("UBI: R/O block driver on top of UBI volumes")
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'for-linus-20140905' of git://git.infradead.org/linux-mtd

2014-09-06T19:12:09+00:00

Pull mtd fixes from Brian Norris:
 "Two trivial MTD updates for 3.17-rc4:

   - a tiny comment tweak, to kill a bunch of DocBook warnings added
     during the merge window

   - a small fixup to the OTP routines' error handling"

* tag 'for-linus-20140905' of git://git.infradead.org/linux-mtd:
  mtd: nand: fix DocBook warnings on nand_sdr_timings doc
  mtd: cfi_cmdset_0002: check return code for get_chip()

mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc()

2014-08-25T23:15:33+00:00

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)

Cc: 	[3.7+]
Signed-off-by: Roger Quadros 
Signed-off-by: Tony Lindgren

mtd: nand: omap: Revert to using software ECC by default

2014-08-25T23:15:32+00:00

For v3.12 and prior, 1-bit Hamming code ECC via software was the
default choice. Commit c66d039197e4 in v3.13 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.12
and prior to be unusable in v3.13 and later. So revert back to
using software ECC by default if an ECC scheme is not explicitely
specified.

This defect can be observed on the following boards during legacy boot

-omap3beagle
-omap3touchbook
-overo
-am3517crane
-devkit8000
-ldp
-3430sdp

Signed-off-by: Roger Quadros 
Tested-by: Grazvydas Ignotas 
Signed-off-by: Tony Lindgren

mtd: cfi_cmdset_0002: check return code for get_chip()

2014-08-16T01:09:00+00:00

Coverity CID 1230633

Signed-off-by: Brian Norris 
Tested-by: Christian Riesch