linux-stable.git/drivers/mtd, branch v3.16.40

ubi: Fix Fastmap's update_vol()

2017-02-23T03:54:08+00:00

commit f7d11b33d4e8cedf19367c09b891bbc705163976 upstream.

Usually Fastmap is free to consider every PEB in one of the pools
as newer than the existing PEB. Since PEBs in a pool are by definition
newer than everything else.
But update_vol() missed the case that a pool can contain more than
one candidate.

Fixes: dbb7d2a88d ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger 
Reviewed-by: Boris Brezillon 
Signed-off-by: Richard Weinberger 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

ubi: Fix races around ubi_refill_pools()

2017-02-23T03:54:08+00:00

commit 2e8f08deabbc7eefe4c5838aaa6aa9a23a8acf2e upstream.

When writing a new Fastmap the first thing that happens
is refilling the pools in memory.
At this stage it is possible that new PEBs from the new pools
get already claimed and written with data.
If this happens before the new Fastmap data structure hits the
flash and we face power cut the freshly written PEB will not
scanned and unnoticed.

Solve the issue by locking the pools until Fastmap is written.

Fixes: dbb7d2a88d ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger 
[bwh: Backported to 3.16:
 - Adjust filename, context, indentation
 - s/ubi->fm_eba_sem/ubi->fm_sem/]
Signed-off-by: Ben Hutchings

ubi: Deal with interrupted erasures in WL

2017-02-23T03:54:08+00:00

commit 2365418879e9abf12ea9def7f9f3caf0dfa7ffb0 upstream.

When Fastmap is used we can face here an -EBADMSG
since Fastmap cannot know about unmaps.
If the erasure was interrupted the PEB may show ECC
errors and UBI would go to ro-mode as it assumes
that the PEB was check during attach time, which is
not the case with Fastmap.

Fixes: dbb7d2a88d ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger 
Signed-off-by: Ben Hutchings

UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header

2017-02-23T03:54:07+00:00

commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.

scan_pool() does not mark the PEB for scrubing when bitflips are
detected in the EC header of a free PEB (VID header region left to
0xff).
Make sure we scrub the PEB in this case.

Signed-off-by: Boris Brezillon 
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger 
Signed-off-by: Ben Hutchings

mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl

2016-11-20T01:17:25+00:00

commit f6d7c1b5598b6407c3f1da795dd54acf99c1990c upstream.

This fixes subpage writes when using 4-bit HW ECC.

There has been numerous reports about ECC errors with devices using this
driver for a while.  Also the 4-bit ECC has been reported as broken with
subpages in [1] and with 16 bits NANDs in the driver and in mach* board
files both in mainline and in the vendor BSPs.

What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to
try reinitializing the ECC engine:
- R/W on whole pages properly generates/checks RS code
- try writing the 1st subpage only of a blank page, the subpage is well
  written and the RS code properly generated, re-reading the same page
  the HW detects some ECC error, reading the same page again no ECC
  error is detected

Note that the ECC engine is already reinitialized in the 1-bit case.

Tested on my LCDK with UBI+UBIFS using subpages.
This could potentially get rid of the issue workarounded in [1].

[1] 28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand")

Fixes: 6a4123e581b3 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage")
Signed-off-by: Karl Beldan 
Acked-by: Boris Brezillon 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings

ubi: Be more paranoid while seaching for the most recent Fastmap

2016-11-20T01:17:01+00:00

commit 74f2c6e9a47cf4e508198c8594626cc82906a13d upstream.

Since PEB erasure is asynchornous it can happen that there is
more than one Fastmap on the MTD. This is fine because the attach logic
will pick the Fastmap data structure with the highest sequence number.

On a not so well configured MTD stack spurious ECC errors are common.
Causes can be different, bad hardware, wrong operating modes, etc...
If the most current Fastmap renders bad due to ECC errors UBI might
pick an older Fastmap to attach from.
While this can only happen on an anyway broken setup it will show
completely different sympthoms and makes finding the root cause much
more difficult.
So, be debug friendly and fall back to scanning mode of we're facing
an ECC error while scanning for Fastmap.

Signed-off-by: Richard Weinberger 
[bwh: Backported to 3.16:
 - In scan_fast(), use 'ai' instead of 'scan_ai'
 - Adjust context]
Signed-off-by: Ben Hutchings

ubi: Make volume resize power cut aware

2016-11-20T01:17:01+00:00

commit 4946784bd3924b1374f05eebff2fd68660bae866 upstream.

When the volume resize operation shrinks a volume,
LEBs will be unmapped. Since unmapping will not erase these
LEBs immediately we have to wait for that operation to finish.
Otherwise in case of a power cut right after writing the new
volume table the UBI attach process can find more LEBs than the
volume table knows. This will render the UBI image unattachable.

Fix this issue by waiting for erase to complete and write the new
volume table afterward.

Reported-by: Boris Brezillon 
Reviewed-by: Boris Brezillon 
Signed-off-by: Richard Weinberger 
Signed-off-by: Ben Hutchings

ubi: Fix race condition between ubi device creation and udev

2016-11-20T01:17:01+00:00

commit 714fb87e8bc05ff78255afc0dca981e8c5242785 upstream.

Install the UBI device object before we arm sysfs.
Otherwise udev tries to read sysfs attributes before UBI is ready and
udev rules will not match.

Signed-off-by: Iosif Harutyunov 
[rw: massaged commit message]
Signed-off-by: Richard Weinberger 
Signed-off-by: Ben Hutchings

mtd: nand: fix bug writing 1 byte less than page size

2016-11-20T01:16:55+00:00

commit 144f4c98399e2c0ca60eb414c15a2c68125c18b8 upstream.

nand_do_write_ops() determines if it is writing a partial page with the
formula:
	part_pagewr = (column || writelen < (mtd->writesize - 1))

When 'writelen' is exactly 1 byte less than the NAND page size the formula
equates to zero, so the code doesn't process it as a partial write,
although it should.
As a consequence the function remains in the while(1) loop with 'writelen'
becoming 0xffffffff and iterating endlessly.

The bug may not be easy to reproduce in Linux since user space tools
usually force the padding or round-up the write size to a page-size
multiple.
This was discovered in U-Boot where the issue can be reproduced by
writing any size that is 1 byte less than a page-size multiple.
For example, on a NAND with 2K page (0x800):
	=> nand erase.part 
	=> nand write $loadaddr  7ff

[Editor's note: the bug was added in commit 29072b96078f, but moved
around in commit 66507c7bc8895 ("mtd: nand: Add support to use nand_base
poi databuf as bounce buffer")]

Fixes: 29072b96078f ("[MTD] NAND: add subpage write support")
Signed-off-by: Hector Palacios 
Acked-by: Boris Brezillon 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings

mtd: pmcmsp-flash: Allocating too much in init_msp_flash()

2016-11-20T01:16:52+00:00

commit 79ad07d45743721010e766e65dc004ad249bd429 upstream.

There is a cut and paste issue here.  The bug is that we are allocating
more memory than necessary for msp_maps.  We should be allocating enough
space for a map_info struct (144 bytes) but we instead allocate enough
for an mtd_info struct (1840 bytes).  It's a small waste.

The other part of this is not harmful but when we allocated msp_flash
then we allocated enough space fro a map_info pointer instead of an
mtd_info pointer.  But since pointers are the same size it works out
fine.

Anyway, I decided to clean up all three allocations a bit to make them
a bit more consistent and clear.

Fixes: 68aa0fa87f6d ('[MTD] PMC MSP71xx flash/rootfs mappings')
Signed-off-by: Dan Carpenter 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings