<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/mtd, branch v3.7</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Revert "revert "Revert "mm: remove __GFP_NO_KSWAPD""" and associated damage</title>
<updated>2012-12-10T19:03:05+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-12-10T18:51:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=caf491916b1c1e939a2c7575efb7a77f11fc9bdf'/>
<id>caf491916b1c1e939a2c7575efb7a77f11fc9bdf</id>
<content type='text'>
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 &lt;mgorman@suse.de&gt;
Acked-by: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Cc: Rik van Riel &lt;riel@redhat.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;mgorman@suse.de&gt;
Acked-by: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Cc: Rik van Riel &lt;riel@redhat.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>UBI: dont call ubi_self_check_all_ff() in __wl_get_peb()</title>
<updated>2012-12-04T14:04:31+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2012-12-03T19:57:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=894aef215775b56b725e9dde856b7a8b091ddfcc'/>
<id>894aef215775b56b725e9dde856b7a8b091ddfcc</id>
<content type='text'>
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 &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>
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 &lt;richard@nod.at&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>UBI: remove PEB from free tree in get_peb_for_wl()</title>
<updated>2012-12-04T14:04:16+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2012-12-03T19:57:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ed4b7021cb51fe5a0f260df03298709347a26967'/>
<id>ed4b7021cb51fe5a0f260df03298709347a26967</id>
<content type='text'>
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 &lt;zsadecki@itwatchdogs.com&gt;
Signed-off-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>
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 &lt;zsadecki@itwatchdogs.com&gt;
Signed-off-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-3.7' of git://git.infradead.org/users/dedekind/l2-mtd</title>
<updated>2012-11-21T10:38:13+00:00</updated>
<author>
<name>David Woodhouse</name>
<email>David.Woodhouse@intel.com</email>
</author>
<published>2012-11-21T10:38:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=851462444d421c223965b12b836bef63da61b57f'/>
<id>851462444d421c223965b12b836bef63da61b57f</id>
<content type='text'>
Conflicts:
	drivers/mtd/nand/nand_base.c
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	drivers/mtd/nand/nand_base.c
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: nand: fix Samsung SLC detection regression</title>
<updated>2012-11-15T13:37:43+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2012-11-15T05:46:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6924d99fcdf1a688538a3cdebd1f135c22eec191'/>
<id>6924d99fcdf1a688538a3cdebd1f135c22eec191</id>
<content type='text'>
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 &lt;sylvester.nawrocki@gmail.com&gt;
Tested-by: Sylwester Nawrocki &lt;sylvester.nawrocki@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&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>
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 &lt;sylvester.nawrocki@gmail.com&gt;
Tested-by: Sylwester Nawrocki &lt;sylvester.nawrocki@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: nand: fix Samsung SLC NAND identification regression</title>
<updated>2012-11-15T13:37:16+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2012-10-10T06:26:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=af451af4e0a3a4cd7536843f585c96a9b095a4e8'/>
<id>af451af4e0a3a4cd7536843f585c96a9b095a4e8</id>
<content type='text'>
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 &lt;computersforpeace@gmail.com&gt;
Tested-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Reported-by: Marek Vasut &lt;marex@denx.de&gt;
Tested-by: Marek Vasut &lt;marex@denx.de&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>
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 &lt;computersforpeace@gmail.com&gt;
Tested-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Reported-by: Marek Vasut &lt;marex@denx.de&gt;
Tested-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: onenand: Make flexonenand_set_boundary static</title>
<updated>2012-11-09T15:02:50+00:00</updated>
<author>
<name>Sachin Kamat</name>
<email>sachin.kamat@linaro.org</email>
</author>
<published>2012-09-22T06:12:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0131950ebd146b5e31508233352d6f4625af25b1'/>
<id>0131950ebd146b5e31508233352d6f4625af25b1</id>
<content type='text'>
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 &lt;sachin.kamat@linaro.org&gt;
Acked-by: Kyungmin Park &lt;kyungmin.park@samsung.com&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>
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 &lt;sachin.kamat@linaro.org&gt;
Acked-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: slram: invalid checking of absolute end address</title>
<updated>2012-11-09T15:02:50+00:00</updated>
<author>
<name>Jiri Engelthaler</name>
<email>engycz@gmail.com</email>
</author>
<published>2012-09-20T14:49:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c36a7ff4578ab6294885aef5ef241aeec4cdb1f0'/>
<id>c36a7ff4578ab6294885aef5ef241aeec4cdb1f0</id>
<content type='text'>
Fixed parsing end absolute address.

Signed-off-by: Jiri Engelthaler &lt;engycz@gmail.com&gt;
Cc: stable@vger.kernel.org
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>
Fixed parsing end absolute address.

Signed-off-by: Jiri Engelthaler &lt;engycz@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: ofpart: Fix incorrect NULL check in parse_ofoldpart_partitions()</title>
<updated>2012-10-10T08:12:39+00:00</updated>
<author>
<name>Sachin Kamat</name>
<email>sachin.kamat@linaro.org</email>
</author>
<published>2012-09-25T09:57:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5a6ea4af0907f995dc06df21a9c9ef764c7cd3bc'/>
<id>5a6ea4af0907f995dc06df21a9c9ef764c7cd3bc</id>
<content type='text'>
The pointer returned by kzalloc should be tested for NULL
to avoid potential NULL pointer dereference later. Incorrect
pointer was being tested for NULL. Bug introduced by commit fbcf62a3
(mtd: physmap_of: move parse_obsolete_partitions to become separate
parser).
This patch fixes this bug.

Cc: Dmitry Eremin-Solenikov &lt;dbaryshkov@gmail.com&gt;
Cc: Artem Bityutskiy &lt;artem.bityutskiy@intel.com&gt;
Cc: stable@kernel.org
Signed-off-by: Sachin Kamat &lt;sachin.kamat@linaro.org&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The pointer returned by kzalloc should be tested for NULL
to avoid potential NULL pointer dereference later. Incorrect
pointer was being tested for NULL. Bug introduced by commit fbcf62a3
(mtd: physmap_of: move parse_obsolete_partitions to become separate
parser).
This patch fixes this bug.

Cc: Dmitry Eremin-Solenikov &lt;dbaryshkov@gmail.com&gt;
Cc: Artem Bityutskiy &lt;artem.bityutskiy@intel.com&gt;
Cc: stable@kernel.org
Signed-off-by: Sachin Kamat &lt;sachin.kamat@linaro.org&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: nand: fix Samsung SLC NAND identification regression</title>
<updated>2012-10-10T06:30:37+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2012-10-10T06:26:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bc86cf7af2ebda88056538e8edff852ee627f76a'/>
<id>bc86cf7af2ebda88056538e8edff852ee627f76a</id>
<content type='text'>
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 &lt;computersforpeace@gmail.com&gt;
Tested-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Reported-by: Marek Vasut &lt;marex@denx.de&gt;
Tested-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;computersforpeace@gmail.com&gt;
Tested-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Reported-by: Marek Vasut &lt;marex@denx.de&gt;
Tested-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
