<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/mmc, branch v3.2.46</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>mmc: atmel-mci: pio hang on block errors</title>
<updated>2013-05-30T13:34:49+00:00</updated>
<author>
<name>Terry Barnaby</name>
<email>terry@beam.ltd.uk</email>
</author>
<published>2013-04-08T16:05:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3c6fc3ed92a2614f0027a778a3598764ace0bb11'/>
<id>3c6fc3ed92a2614f0027a778a3598764ace0bb11</id>
<content type='text'>
commit bdbc5d0c60f3e9de3eeccf1c1a18bdc11dca62cc upstream.

The driver is doing, by default, multi-block reads. When a block error
occurs, card/block.c instigates a single block read: "mmcblk0: retrying
using single block read".  It leaves the sg chain intact and just changes
the length attribute for the first sg entry and the overall sg_len
parameter.  When atmci_read_data_pio is called to read the single block
of data it ignores the sg_len and expects to read more than 512 bytes as
it sees there are multiple items in the sg list. No more data comes as
the controller has only been commanded to get one block.

Signed-off-by: Terry Barnaby &lt;terry@beam.ltd.uk&gt;
Acked-by: Ludovic Desroches &lt;ludovic.desroches@atmel.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bdbc5d0c60f3e9de3eeccf1c1a18bdc11dca62cc upstream.

The driver is doing, by default, multi-block reads. When a block error
occurs, card/block.c instigates a single block read: "mmcblk0: retrying
using single block read".  It leaves the sg chain intact and just changes
the length attribute for the first sg entry and the overall sg_len
parameter.  When atmci_read_data_pio is called to read the single block
of data it ignores the sg_len and expects to read more than 512 bytes as
it sees there are multiple items in the sg list. No more data comes as
the controller has only been commanded to get one block.

Signed-off-by: Terry Barnaby &lt;terry@beam.ltd.uk&gt;
Acked-by: Ludovic Desroches &lt;ludovic.desroches@atmel.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: Fix bit width test failing on old eMMC cards</title>
<updated>2013-05-30T13:34:49+00:00</updated>
<author>
<name>Philip Rakity</name>
<email>prakity@yahoo.com</email>
</author>
<published>2013-04-04T19:18:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9126ab0cea7cde9180ed18c72997cadff18f6213'/>
<id>9126ab0cea7cde9180ed18c72997cadff18f6213</id>
<content type='text'>
commit 836dc2fe89c968c10cada87e0dfae6626f8f9da3 upstream.

PARTITION_SUPPORT needs to be set before doing the compare on version
number so the bit width test does not get invalid data.  Before this
patch, a Sandisk iNAND eMMC card would detect 1-bit width although
the hardware supports 4-bit.

Only affects old emmc devices - pre 4.4 devices.

Reported-by: Elad Yi &lt;elad.yi@gmail.com&gt;
Signed-off-by: Philip Rakity &lt;prakity@yahoo.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 836dc2fe89c968c10cada87e0dfae6626f8f9da3 upstream.

PARTITION_SUPPORT needs to be set before doing the compare on version
number so the bit width test does not get invalid data.  Before this
patch, a Sandisk iNAND eMMC card would detect 1-bit width although
the hardware supports 4-bit.

Only affects old emmc devices - pre 4.4 devices.

Reported-by: Elad Yi &lt;elad.yi@gmail.com&gt;
Signed-off-by: Philip Rakity &lt;prakity@yahoo.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: at91/avr32/atmel-mci: fix DMA-channel leak on module unload</title>
<updated>2013-05-30T13:34:48+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2013-03-13T16:11:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=29878cdb099a4703b884aa1e0354fedff9766133'/>
<id>29878cdb099a4703b884aa1e0354fedff9766133</id>
<content type='text'>
commit 91cf54feecf815bec0b6a8d6d9dbd0e219f2f2cc upstream.

Fix regression introduced by commit 796211b7953 ("mmc: atmel-mci: add
pdc support and runtime capabilities detection") which removed the need
for CONFIG_MMC_ATMELMCI_DMA but kept the Kconfig-entry as well as the
compile guards around dma_release_channel() in remove(). Consequently,
DMA is always enabled (if supported), but the DMA-channel is not
released on module unload unless the DMA-config option is selected.

Remove the no longer used CONFIG_MMC_ATMELMCI_DMA option completely.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Acked-by: Ludovic Desroches &lt;ludovic.desroches@atmel.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 91cf54feecf815bec0b6a8d6d9dbd0e219f2f2cc upstream.

Fix regression introduced by commit 796211b7953 ("mmc: atmel-mci: add
pdc support and runtime capabilities detection") which removed the need
for CONFIG_MMC_ATMELMCI_DMA but kept the Kconfig-entry as well as the
compile guards around dma_release_channel() in remove(). Consequently,
DMA is always enabled (if supported), but the DMA-channel is not
released on module unload unless the DMA-config option is selected.

Remove the no longer used CONFIG_MMC_ATMELMCI_DMA option completely.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Acked-by: Ludovic Desroches &lt;ludovic.desroches@atmel.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci-esdhc-imx: fix host version read</title>
<updated>2013-03-06T03:24:13+00:00</updated>
<author>
<name>Shawn Guo</name>
<email>shawn.guo@linaro.org</email>
</author>
<published>2013-01-15T15:30:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e3efb0af9406a25d27c03407c288b187c95e8244'/>
<id>e3efb0af9406a25d27c03407c288b187c95e8244</id>
<content type='text'>
commit ef4d0888bb7e1b963880f086575081c3d39cad2d upstream.

When commit 95a2482 (mmc: sdhci-esdhc-imx: add basic imx6q usdhc
support) works around host version issue on imx6q, it gets the
register address fixup "reg ^= 2" lost for imx25/35/51/53 esdhc.
Thus, the controller version on these SoCs is wrongly identified
as v1 while it's actually v2.

Add the address fixup back and take a different approach to correct
imx6q host version, so that the host version read gets back to work
for all SoCs.

Signed-off-by: Shawn Guo &lt;shawn.guo@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ef4d0888bb7e1b963880f086575081c3d39cad2d upstream.

When commit 95a2482 (mmc: sdhci-esdhc-imx: add basic imx6q usdhc
support) works around host version issue on imx6q, it gets the
register address fixup "reg ^= 2" lost for imx25/35/51/53 esdhc.
Thus, the controller version on these SoCs is wrongly identified
as v1 while it's actually v2.

Add the address fixup back and take a different approach to correct
imx6q host version, so that the host version read gets back to work
for all SoCs.

Signed-off-by: Shawn Guo &lt;shawn.guo@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert misapplied "mmc: sh-mmcif: avoid oops on spurious interrupts"</title>
<updated>2013-01-03T03:32:54+00:00</updated>
<author>
<name>Chris Ball</name>
<email>cjb@laptop.org</email>
</author>
<published>2012-12-03T14:17:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d8c2239fcc2c65572d199b010f7903d05a839502'/>
<id>d8c2239fcc2c65572d199b010f7903d05a839502</id>
<content type='text'>
commit 6984f3c31bb57cb7491dbec1be44b74bd00f4648 upstream.

This reverts commit 8464dd52d3198dd05, which was a misapplied debugging
version of the patch, not the final patch itself.

Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6984f3c31bb57cb7491dbec1be44b74bd00f4648 upstream.

This reverts commit 8464dd52d3198dd05, which was a misapplied debugging
version of the patch, not the final patch itself.

Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci-s3c: fix the wrong number of max bus clocks</title>
<updated>2012-10-17T02:49:43+00:00</updated>
<author>
<name>Jaehoon Chung</name>
<email>jh80.chung@samsung.com</email>
</author>
<published>2012-09-19T06:43:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=664f857bc07bf8e327b0f1271d3490c7af4a5195'/>
<id>664f857bc07bf8e327b0f1271d3490c7af4a5195</id>
<content type='text'>
commit 5feb54a1ab91a237e247c013b8c4fb100ea347b1 upstream.

We can use up to four bus-clocks; but on module remove, we didn't
disable the fourth bus clock.

Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5feb54a1ab91a237e247c013b8c4fb100ea347b1 upstream.

We can use up to four bus-clocks; but on module remove, we didn't
disable the fourth bus clock.

Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sh-mmcif: avoid oops on spurious interrupts</title>
<updated>2012-10-17T02:49:28+00:00</updated>
<author>
<name>Guennadi Liakhovetski</name>
<email>g.liakhovetski@gmx.de</email>
</author>
<published>2012-09-18T06:42:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cf06b5a1c78a13ff25d8b2d367770b2936316006'/>
<id>cf06b5a1c78a13ff25d8b2d367770b2936316006</id>
<content type='text'>
commit 8464dd52d3198dd05cafb005371d76e5339eb842 upstream.

On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
interrupts without any active request. To prevent the Oops, that results
in such cases, don't dereference the mmc request pointer until we make
sure, that we are indeed processing such a request.

Reported-by: Tetsuyuki Kobayashi &lt;koba@kmckk.co.jp&gt;
Signed-off-by: Guennadi Liakhovetski &lt;g.liakhovetski@gmx.de&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8464dd52d3198dd05cafb005371d76e5339eb842 upstream.

On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
interrupts without any active request. To prevent the Oops, that results
in such cases, don't dereference the mmc request pointer until we make
sure, that we are indeed processing such a request.

Reported-by: Tetsuyuki Kobayashi &lt;koba@kmckk.co.jp&gt;
Signed-off-by: Guennadi Liakhovetski &lt;g.liakhovetski@gmx.de&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: omap_hsmmc: Pass on the suspend failure to the PM core</title>
<updated>2012-10-17T02:49:27+00:00</updated>
<author>
<name>Vaibhav Bedia</name>
<email>vaibhav.bedia@ti.com</email>
</author>
<published>2012-09-13T06:31:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b1f9cafbf2313768160d3d2587deba1f099fc5f5'/>
<id>b1f9cafbf2313768160d3d2587deba1f099fc5f5</id>
<content type='text'>
commit c4c8eeb4df00aabb641553d6fbcd46f458e56cd9 upstream.

In some cases mmc_suspend_host() is not able to claim the
host and proceed with the suspend process. The core returns
-EBUSY to the host controller driver. Unfortunately, the
host controller driver does not pass on this information
to the PM core and hence the system suspend process continues.

	ret = mmc_suspend_host(host-&gt;mmc);
	if (ret) {
		host-&gt;suspended = 0;
		if (host-&gt;pdata-&gt;resume) {
			ret = host-&gt;pdata-&gt;resume(dev, host-&gt;slot_id);

The return status from mmc_suspend_host() is overwritten by return
status from host-&gt;pdata-&gt;resume. So the original return status is lost.

In these cases the MMC core gets to an unexpected state
during resume and multiple issues related to MMC crop up.
1. Host controller driver starts accessing the device registers
before the clocks are enabled which leads to a prefetch abort.
2. A file copy thread which was launched before suspend gets
stuck due to the host not being reclaimed during resume.

To avoid such problems pass on the -EBUSY status to the PM core
from the host controller driver. With this change, MMC core
suspend might still fail but it does not end up making the
system unusable. Suspend gets aborted and the user can try
suspending the system again.

Signed-off-by: Vaibhav Bedia &lt;vaibhav.bedia@ti.com&gt;
Signed-off-by: Hebbar, Gururaja &lt;gururaja.hebbar@ti.com&gt;
Acked-by: Venkatraman S &lt;svenkatr@ti.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2:
 - Adjust context, indentation
 - s/dev/\&amp;pdev-&gt;dev/]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c4c8eeb4df00aabb641553d6fbcd46f458e56cd9 upstream.

In some cases mmc_suspend_host() is not able to claim the
host and proceed with the suspend process. The core returns
-EBUSY to the host controller driver. Unfortunately, the
host controller driver does not pass on this information
to the PM core and hence the system suspend process continues.

	ret = mmc_suspend_host(host-&gt;mmc);
	if (ret) {
		host-&gt;suspended = 0;
		if (host-&gt;pdata-&gt;resume) {
			ret = host-&gt;pdata-&gt;resume(dev, host-&gt;slot_id);

The return status from mmc_suspend_host() is overwritten by return
status from host-&gt;pdata-&gt;resume. So the original return status is lost.

In these cases the MMC core gets to an unexpected state
during resume and multiple issues related to MMC crop up.
1. Host controller driver starts accessing the device registers
before the clocks are enabled which leads to a prefetch abort.
2. A file copy thread which was launched before suspend gets
stuck due to the host not being reclaimed during resume.

To avoid such problems pass on the -EBUSY status to the PM core
from the host controller driver. With this change, MMC core
suspend might still fail but it does not end up making the
system unusable. Suspend gets aborted and the user can try
suspending the system again.

Signed-off-by: Vaibhav Bedia &lt;vaibhav.bedia@ti.com&gt;
Signed-off-by: Hebbar, Gururaja &lt;gururaja.hebbar@ti.com&gt;
Acked-by: Venkatraman S &lt;svenkatr@ti.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2:
 - Adjust context, indentation
 - s/dev/\&amp;pdev-&gt;dev/]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: Prevent 1.8V switch for SD hosts that don't support UHS modes.</title>
<updated>2012-10-10T02:31:11+00:00</updated>
<author>
<name>Al Cooper</name>
<email>acooper@gmail.com</email>
</author>
<published>2012-03-16T19:54:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=26fb1ba1baf9fe555ff2918e027cef78ee3f54d0'/>
<id>26fb1ba1baf9fe555ff2918e027cef78ee3f54d0</id>
<content type='text'>
commit 4188bba0e9e7ba58d231b528df495666f2742b74 upstream.

The driver should not try to switch to 1.8V when the SD 3.0 host
controller does not have any UHS capabilities bits set (SDR50, DDR50
or SDR104). See page 72 of "SD Specifications Part A2 SD Host
Controller Simplified Specification Version 3.00" under
"1.8V Signaling Enable". Instead of setting SDR12 and SDR25 in the host
capabilities data structure for all V3.0 host controllers, only set them
if SDR104, SDR50 or DDR50 is set in the host capabilities register. This
will prevent the switch to 1.8V later.

Signed-off-by: Al Cooper &lt;acooper@gmail.com&gt;
Acked-by: Arindam Nath &lt;arindam.nath@amd.com&gt;
Acked-by: Philip Rakity &lt;prakity@marvell.com&gt;
Acked-by: Girish K S &lt;girish.shivananjappa@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4188bba0e9e7ba58d231b528df495666f2742b74 upstream.

The driver should not try to switch to 1.8V when the SD 3.0 host
controller does not have any UHS capabilities bits set (SDR50, DDR50
or SDR104). See page 72 of "SD Specifications Part A2 SD Host
Controller Simplified Specification Version 3.00" under
"1.8V Signaling Enable". Instead of setting SDR12 and SDR25 in the host
capabilities data structure for all V3.0 host controllers, only set them
if SDR104, SDR50 or DDR50 is set in the host capabilities register. This
will prevent the switch to 1.8V later.

Signed-off-by: Al Cooper &lt;acooper@gmail.com&gt;
Acked-by: Arindam Nath &lt;arindam.nath@amd.com&gt;
Acked-by: Philip Rakity &lt;prakity@marvell.com&gt;
Acked-by: Girish K S &lt;girish.shivananjappa@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.</title>
<updated>2012-09-19T14:04:40+00:00</updated>
<author>
<name>Ian Chen</name>
<email>ian.cy.chen@samsung.com</email>
</author>
<published>2012-08-29T06:05:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3b75588b26cc22a16ff812e38ba7720b3e2d9b38'/>
<id>3b75588b26cc22a16ff812e38ba7720b3e2d9b38</id>
<content type='text'>
commit 3550ccdb9d8d350e526b809bf3dd92b550a74fe1 upstream.

For several MoviNAND eMMC parts, there are known issues with secure
erase and secure trim.  For these specific MoviNAND devices, we skip
these operations.

Specifically, there is a bug in the eMMC firmware that causes
unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE
enabled.

References:

http://forum.xda-developers.com/showthread.php?t=1644364
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB

Signed-off-by: Ian Chen &lt;ian.cy.chen@samsung.com&gt;
Reviewed-by: Namjae Jeon &lt;linkinjeon@gmail.com&gt;
Acked-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3550ccdb9d8d350e526b809bf3dd92b550a74fe1 upstream.

For several MoviNAND eMMC parts, there are known issues with secure
erase and secure trim.  For these specific MoviNAND devices, we skip
these operations.

Specifically, there is a bug in the eMMC firmware that causes
unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE
enabled.

References:

http://forum.xda-developers.com/showthread.php?t=1644364
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB

Signed-off-by: Ian Chen &lt;ian.cy.chen@samsung.com&gt;
Reviewed-by: Namjae Jeon &lt;linkinjeon@gmail.com&gt;
Acked-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
