<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/mmc/host, branch linux-3.6.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-3.6.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-3.6.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2012-12-17T17:26:51+00:00</updated>
<entry>
<title>mmc: sh-mmcif: avoid oops on spurious interrupts (second try)</title>
<updated>2012-12-17T17:26:51+00:00</updated>
<author>
<name>Guennadi Liakhovetski</name>
<email>g.liakhovetski@gmx.de</email>
</author>
<published>2012-08-22T06:49:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=13837cb45c779fff942d2b08af1d0c7551c4ffc6'/>
<id>urn:sha1:13837cb45c779fff942d2b08af1d0c7551c4ffc6</id>
<content type='text'>
commit 91ab252ac5a5c3461dd6910797611e9172626aed 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;
Tested-by: Tetsuyuki Kobayashi &lt;koba@kmckk.co.jp&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Revert misapplied "mmc: sh-mmcif: avoid oops on spurious interrupts"</title>
<updated>2012-12-17T17:26:50+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.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d4e36db25e78820d04081c7c1e8ad5ce616280e7'/>
<id>urn:sha1:d4e36db25e78820d04081c7c1e8ad5ce616280e7</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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-s3c: fix the wrong number of max bus clocks</title>
<updated>2012-12-03T19:38:15+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.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2087b40bec809ed98810ca80526ae092f58ac5d9'/>
<id>urn:sha1:2087b40bec809ed98810ca80526ae092f58ac5d9</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;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci: fix NULL dereference in sdhci_request() tuning</title>
<updated>2012-11-17T21:19:05+00:00</updated>
<author>
<name>Chris Ball</name>
<email>cjb@laptop.org</email>
</author>
<published>2012-11-05T19:29:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2091b753133a0bd22439357ed13f68fa595b8dd7'/>
<id>urn:sha1:2091b753133a0bd22439357ed13f68fa595b8dd7</id>
<content type='text'>
commit 14efd957209461bbdf285bf0d67e931955d04a4c upstream.

Commit 473b095a72a9 ("mmc: sdhci: fix incorrect command used in tuning")
introduced a NULL dereference at resume-time if an SD 3.0 host controller
raises the SDHCI_NEEDS_TUNING flag while no card is inserted.  Seen on an
OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too.

Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sh_mmcif: fix use after free</title>
<updated>2012-11-17T21:19:05+00:00</updated>
<author>
<name>Guennadi Liakhovetski</name>
<email>g.liakhovetski@gmx.de</email>
</author>
<published>2012-10-23T12:08:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2d2db636c0f85a0fa4da6b6bc82d3474745b10de'/>
<id>urn:sha1:2d2db636c0f85a0fa4da6b6bc82d3474745b10de</id>
<content type='text'>
commit a0d28ba01ebd048b4ba418142b37f5cf80e6d156 upstream.

A recent commit "mmc: sh_mmcif: fix clock management" has introduced a
use after free bug in sh_mmcif.c: in sh_mmcif_remove() the call to
mmc_free_host() frees private driver data, therefore using it afterwards
is a bug. Revert that hunk.

Signed-off-by: Guennadi Liakhovetski &lt;g.liakhovetski@gmx.de&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sh-mmcif: avoid oops on spurious interrupts</title>
<updated>2012-10-12T20:50:34+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.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c63c3bf3e32a13c22edff2a9cc7310a46092e70'/>
<id>urn:sha1:8c63c3bf3e32a13c22edff2a9cc7310a46092e70</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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: omap_hsmmc: Pass on the suspend failure to the PM core</title>
<updated>2012-10-12T20:50:34+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.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=07c0544659b0d75a7b649b37ab5641fa0a3eec2c'/>
<id>urn:sha1:07c0544659b0d75a7b649b37ab5641fa0a3eec2c</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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: omap: fix broken PIO mode</title>
<updated>2012-09-04T17:58:11+00:00</updated>
<author>
<name>Paul Walmsley</name>
<email>paul@pwsan.com</email>
</author>
<published>2012-08-24T06:00:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=75b53aee2f4fe6375c6007226bf68d75b5c4a929'/>
<id>urn:sha1:75b53aee2f4fe6375c6007226bf68d75b5c4a929</id>
<content type='text'>
After commit 26b88520b80695a6fa5fd95b5d97c03f4daf87e0 ("mmc:
omap_hsmmc: remove private DMA API implementation"), the Nokia N800
here stopped booting:

[    2.086181] Waiting for root device /dev/mmcblk0p1...
[    2.324066] Unhandled fault: imprecise external abort (0x406) at 0x00000000
[    2.331451] Internal error: : 406 [#1] ARM
[    2.335784] Modules linked in:
[    2.339050] CPU: 0    Not tainted  (3.6.0-rc3 #60)
[    2.344146] PC is at default_idle+0x28/0x30
[    2.348602] LR is at trace_hardirqs_on_caller+0x15c/0x1b0

...

This turned out to be due to memory corruption caused by long-broken
PIO code in drivers/mmc/host/omap.c.  (Previously, this driver had
been using DMA; but the above commit caused the MMC driver to fall
back to PIO mode with an unmodified Kconfig.)

The PIO code, added with the rest of the driver in commit
730c9b7e6630f786fcec026fb11d2e6f2c90fdcb ("[MMC] Add OMAP MMC host
driver"), confused bytes with 16-bit words.  This bug caused memory
located after the PIO transfer buffer to be corrupted with transfers
larger than 32 bytes.  The driver also did not increment the buffer
pointer after the transfer occurred.  This bug resulted in data
corruption during any transfer larger than 64 bytes.

Signed-off-by: Paul Walmsley &lt;paul@pwsan.com&gt;
Reviewed-by: Felipe Balbi &lt;balbi@ti.com&gt;
Tested-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: dw_mmc: Disable low power mode if SDIO interrupts are used</title>
<updated>2012-09-04T17:58:10+00:00</updated>
<author>
<name>Doug Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2012-07-25T15:33:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9623b5b9192b349bcadb31cce159072a78ac6972'/>
<id>urn:sha1:9623b5b9192b349bcadb31cce159072a78ac6972</id>
<content type='text'>
The documentation for the dw_mmc part says that the low power
mode should normally only be set for MMC and SD memory and should
be turned off for SDIO cards that need interrupts detected.

The best place I could find to do this is when the SDIO interrupt
was first enabled.  I rely on the fact that dw_mci_setup_bus()
will be called when it's time to reenable.

Signed-off-by: Doug Anderson &lt;dianders@chromium.org&gt;
Acked-by: Seungwon Jeon &lt;tgih.jun@samsung.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: dw_mmc: fix error handling in PIO mode</title>
<updated>2012-09-04T17:58:09+00:00</updated>
<author>
<name>Seungwon Jeon</name>
<email>tgih.jun@samsung.com</email>
</author>
<published>2012-08-01T00:30:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e74f3a9c993a088f0a067e13941075e4acb7300a'/>
<id>urn:sha1:e74f3a9c993a088f0a067e13941075e4acb7300a</id>
<content type='text'>
Data transfer will be continued until all the bytes are transmitted,
even if data crc error occurs during a multiple-block data transfer.
This means RXDR/TXDR interrupts will occurs until data transfer is
terminated. Early setting of host-&gt;sg to NULL prevents going into
xxx_data_pio functions, hence permanent unhandled RXDR/TXDR interrupts
occurs. And checking error interrupt status in the xxx_data_pio functions
is no need because dw_mci_interrupt does do the same. This patch also
removes it.

Signed-off-by: Seungwon Jeon &lt;tgih.jun@samsung.com&gt;
Acked-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Acked-by: Will Newton &lt;will.newton@imgtec.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
</feed>
