linux-toradex.git/drivers/mtd, branch v3.7.4

mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems

2013-01-17T16:46:08+00:00

commit 6f2a6a52560ad8d85710aabd92b7a3239b3a6b07 upstream.

It could happen (1 out of 100 times) that NAND did not start up
correctly after warm rebooting, so the kernel could not find the UBI or
DMA timed out due to a stalled BCH. When resetting BCH together with
GPMI, the issue could not be observed anymore (after 10000+ reboots). We
probably need the consistent state already before sending any command to
NAND, even when no ECC is needed. I chose to keep the extra reset for
BCH when changing the flash layout to be on the safe side.

Signed-off-by: Wolfram Sang 
Acked-by: Huang Shijie 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman

mtd cs553x_nand: Initialise ecc.strength before nand_scan()

2013-01-17T16:46:05+00:00

commit d1f3b65d2d6fdb4bf0edd4b67e86e191af48daee upstream.

Loading cs553x_nand with Hynix H27U1G8F2BTR NAND flash causes this bug:

kernel BUG at drivers/mtd/nand/nand_base.c:3345!
invalid opcode: 0000 [#1]
Modules linked in: cs553x_nand(+) vfat fat usb_storage ehci_hcd usbcore usb_comr
Pid: 436, comm: modprobe Not tainted 3.6.7 #1
EIP: 0060:[] EFLAGS: 00010296 CPU: 0
EIP is at nand_scan_tail+0x64c/0x69c
EAX: 00000034 EBX: cea6ed98 ECX: 00000000 EDX: 00000000
ESI: cea6ec00 EDI: cea6ec00 EBP: 20000000 ESP: cdd17e48
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
CR0: 8005003b CR2: 0804e119 CR3: 0d850000 CR4: 00000090
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process modprobe (pid: 436, ti=cdd16000 task=cdd1c320 task.ti=cdd16000)
Stack:
 c12e962c c118f7ef 00000003 cea6ed98 d014b25c 20000000 fffff007 00000001
 00000000 cdd53b00 d014b000 c1001021 cdd53b00 d01493c0 cdd53b00 cdd53b00
 d01493c0 c1047f83 d014b4a0 00000000 cdd17f9c ce4be454 cdd17f48 cdd1c320
Call Trace:
 [] ? nand_scan+0x1b/0x4d
 [] ? init_module+0x25c/0x2de [cs553x_nand]
 [] ? 0xd014afff
 [] ? do_one_initcall+0x21/0x111
 [] ? sys_init_module+0xe4/0x1261
 [] ? task_work_run+0x36/0x43
 [] ? syscall_call+0x7/0xb
Code: fa ff ff c7 86 d8 00 00 00 01 00 00 00 e9 5f fc ff ff 68 f8 26 2e c1 e8 a7
EIP: [] nand_scan_tail+0x64c/0x69c SS:ESP 0068:cdd17e48

Initialising ecc.strength before the call to nand_scan() fixes this.

Signed-off-by: Nathan Williams 
Acked-by: Brian Norris 
Acked-by: Mike Dunn 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman

Revert "revert "Revert "mm: remove __GFP_NO_KSWAPD""" and associated damage

2012-12-10T19:03:05+00:00

This reverts commits a50915394f1fc02c2861d3b7ce7014788aa5066e and
d7c3b937bdf45f0b844400b7bf6fd3ed50bac604.

This is a revert of a revert of a revert.  In addition, it reverts the
even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the
original commits in linux-next.

It turns out that the original patch really was bogus, and that the
original revert was the correct thing to do after all.  We thought we
had fixed the problem, and then reverted the revert, but the problem
really is fundamental: waking up kswapd simply isn't the right thing to
do, and direct reclaim sometimes simply _is_ the right thing to do.

When certain allocations fail, we simply should try some direct reclaim,
and if that fails, fail the allocation.  That's the right thing to do
for THP allocations, which can easily fail, and the GPU allocations want
to do that too.

So starting kswapd is sometimes simply wrong, and removing the flag that
said "don't start kswapd" was a mistake.  Let's hope we never revisit
this mistake again - and certainly not this many times ;)

Acked-by: Mel Gorman 
Acked-by: Johannes Weiner 
Cc: Rik van Riel 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds

UBI: dont call ubi_self_check_all_ff() in __wl_get_peb()

2012-12-04T14:04:31+00:00

As ubi_self_check_all_ff() might sleep we are not allowed
to call it from atomic context.
For now we call it only from ubi_wl_get_peb().
There are some code paths where it would also make sense,
but these paths are currently atomic and only enabled
when fastmap is used.

Signed-off-by: Richard Weinberger 
Signed-off-by: Artem Bityutskiy

UBI: remove PEB from free tree in get_peb_for_wl()

2012-12-04T14:04:16+00:00

If UBI is built without fastmap, get_peb_for_wl() has to
remove the PEB manially from the free tree.
Otherwise the requested PEB lives in two trees.

Reported-by: Zach Sadecki 
Signed-off-by: Richard Weinberger 
Signed-off-by: Artem Bityutskiy

Merge branch 'for-3.7' of git://git.infradead.org/users/dedekind/l2-mtd

2012-11-21T10:38:13+00:00

Conflicts:
	drivers/mtd/nand/nand_base.c

mtd: nand: fix Samsung SLC detection regression

2012-11-15T13:37:43+00:00

This patch fixes errors seen in identifying old Samsung SLC, due to the
following commits:

    commit e2d3a35ee427aaba99b6c68a56609ce276c51270
    mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID

    commit e3b88bd604283ef83ae6e8f53622d5b1ffe9d43a
    mtd: nand: add generic READ ID length calculation functions

Some Samsung NAND with "5-byte" ID really appear to have 6-byte IDs, with
wraparound like:

  Samsung K9K8G08U0D
  ec d3 51 95 58 ec ec d3

  Samsung K9F1G08U0C
  ec f1 00 95 40 ec ec f1

  Samsung K9F2G08U0B
  ec da 10 95 44 00 ec da

This bad wraparound makes it hard to reliably detect the difference
between Samsung SLC with 5-byte ID and Samsung SLC with 6-byte ID.

The fix is to, for now, only use the new Samsung table for MLC. We
cannot support the new SLC (K9FAG08U0M) until Samsung gives better ID
decode information.

Note that this applies in addition to the previous regression fix:

    commit bc86cf7af2ebda88056538e8edff852ee627f76a
    mtd: nand: fix Samsung SLC NAND identification regression

Together, these patches completely restore the previous detection
behavior so that we cannot see any more regressions in Samsung SLC NAND
(finger crossed). With luck, I can get a hold of a Samsung
representative and stop having to cross my fingers eventually.

Reported-by: Sylwester Nawrocki 
Tested-by: Sylwester Nawrocki 
Signed-off-by: Brian Norris 
Signed-off-by: Artem Bityutskiy

mtd: nand: fix Samsung SLC NAND identification regression

2012-11-15T13:37:16+00:00

A combination of the following two commits caused a regression in 3.7-rc1
when identifying some Samsung NAND, so that some previously working NAND
were no longer detected properly:

    commit e3b88bd604283ef83ae6e8f53622d5b1ffe9d43a
    mtd: nand: add generic READ ID length calculation functions

    commit e2d3a35ee427aaba99b6c68a56609ce276c51270
    mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID

Particularly, a regression was seen on Samsung K9F2G08U0B, with the
following full 8-byte READ ID string:

    ec da 10 95 44 00 ec da

The basic problem is that Samsung manufactures both SLC and MLC NAND
that use a non-standard decoding table for deriving information from
their IDs. I have heuristically determined that all the chips that use
the new table have ID strings which wrap around after the 6th byte.
Unfortunately, I overlooked the fact that some older Samsung SLC (which
use a different decoding table) have "5 byte ID strings" which also wrap
around after the 6th byte.

This patch re-introduces a distinction between these old and new Samsung
NAND by checking that the 6th byte is non-zero, allowing both old and
new Samsung NAND to be detected properly.

Signed-off-by: Brian Norris 
Tested-by: Brian Norris 
Reported-by: Marek Vasut 
Tested-by: Marek Vasut 
Signed-off-by: Artem Bityutskiy

mtd: onenand: Make flexonenand_set_boundary static

2012-11-09T15:02:50+00:00

Fixes the following sparse warning:
drivers/mtd/onenand/onenand_base.c:3697:5: warning:
symbol 'flexonenand_set_boundary' was not declared. Should it be static?

Signed-off-by: Sachin Kamat 
Acked-by: Kyungmin Park 
Signed-off-by: Artem Bityutskiy

mtd: slram: invalid checking of absolute end address

2012-11-09T15:02:50+00:00

Fixed parsing end absolute address.

Signed-off-by: Jiri Engelthaler 
Cc: stable@vger.kernel.org
Signed-off-by: Artem Bityutskiy