<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/mmc, branch linux-2.6.35.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-2.6.35.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-2.6.35.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2011-08-01T20:54:43+00:00</updated>
<entry>
<title>mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finish</title>
<updated>2011-08-01T20:54:43+00:00</updated>
<author>
<name>Chris Ball</name>
<email>cjb@laptop.org</email>
</author>
<published>2011-04-27T21:35:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=882041535c8d3244c46bcca0f2109ac514e74dd5'/>
<id>urn:sha1:882041535c8d3244c46bcca0f2109ac514e74dd5</id>
<content type='text'>
commit 0c9c99a765321104cc5f9c97f949382a9ba4927e upstream.

It seems that under certain circumstances the sdhci_tasklet_finish()
call can be entered with mrq set to NULL, causing the system to crash
with a NULL pointer de-reference.

Seen on S3C6410 system.  Based on a patch by Dimitris Papastamos.

Reported-by: Dimitris Papastamos &lt;dp@opensource.wolfsonmicro.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci: Check mrq-&gt;cmd in sdhci_tasklet_finish</title>
<updated>2011-08-01T20:54:43+00:00</updated>
<author>
<name>Ben Dooks</name>
<email>ben-linux@fluff.org</email>
</author>
<published>2011-04-27T13:24:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c8e95fea6c5c922ecdfde9d41f460dcc2e797e4'/>
<id>urn:sha1:5c8e95fea6c5c922ecdfde9d41f460dcc2e797e4</id>
<content type='text'>
commit b7b4d3426d2b5ecab21578eb20d8e456a1aace8f upstream.

It seems that under certain circumstances that the sdhci_tasklet_finish()
call can be entered with mrq-&gt;cmd set to NULL, causing the system to crash
with a NULL pointer de-reference.

Unable to handle kernel NULL pointer dereference at virtual address 00000000
PC is at sdhci_tasklet_finish+0x34/0xe8
LR is at sdhci_tasklet_finish+0x24/0xe8

Seen on S3C6410 system.

Signed-off-by: Ben Dooks &lt;ben-linux@fluff.org&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-pci: Fix error case in sdhci_pci_probe_slot()</title>
<updated>2011-08-01T20:54:43+00:00</updated>
<author>
<name>Chris Ball</name>
<email>cjb@laptop.org</email>
</author>
<published>2011-03-29T04:46:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=725296955c01285787cdfbaf813298626c9c09ee'/>
<id>urn:sha1:725296955c01285787cdfbaf813298626c9c09ee</id>
<content type='text'>
commit 9fdcdbb0d84922e7ccda2f717a04ea62629f7e18 upstream.

If pci_ioremap_bar() fails during probe, we "goto release;" and free the
host, but then we return 0 -- which tells sdhci_pci_probe() that the probe
succeeded.  Since we think the probe succeeded, when we unload sdhci we'll
go to sdhci_pci_remove_slot() and it will try to dereference slot-&gt;host,
which is now NULL because we freed it in the error path earlier.

The patch simply sets ret appropriately, so that sdhci_pci_probe() will
detect the failure immediately and bail out.

Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;

</content>
</entry>
<entry>
<title>mmc: sdio: remember new card RCA when redetecting card</title>
<updated>2011-03-31T18:58:43+00:00</updated>
<author>
<name>Stefan Nilsson XK</name>
<email>stefan.xk.nilsson@stericsson.com</email>
</author>
<published>2011-03-01T13:41:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5857fb84e4065b8e502f8eb1db4041aa69d51812'/>
<id>urn:sha1:5857fb84e4065b8e502f8eb1db4041aa69d51812</id>
<content type='text'>
commit 0aab3995485b8a994bf29a995a008c9ea4a28054 upstream.

During redetection of a SDIO card, a request for a new card RCA
was submitted to the card, but was then overwritten by the old RCA.
This caused the card to be deselected instead of selected when using
the incorrect RCA.  This bug's been present since the "oldcard"
handling was introduced in 2.6.32.

Signed-off-by: Stefan Nilsson XK &lt;stefan.xk.nilsson@stericsson.com&gt;
Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;
Reviewed-by: Ulf Hansson &lt;ulf.hansson@stericsson.com&gt;
Reviewed-by: Pawel Wieczorkiewicz &lt;pawel.wieczorkiewicz@stericsson.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>mmc: Fix re-probing with PM_POST_RESTORE notification</title>
<updated>2011-02-06T19:03:48+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2010-12-10T07:40:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=01dda54376c56e99e475193d6c112f05476e5280'/>
<id>urn:sha1:01dda54376c56e99e475193d6c112f05476e5280</id>
<content type='text'>
commit 274476f8fe0b6ac9bac542cc39de12c3dd0f43f6 upstream.

In the error-path where PM notifies PM_POST_RESTORE, the rescan-blockage
should be cleared as well.  Otherwise it'll be never re-probed.

Also, as a bonus, this fixes a bug in S4 with user-mode suspend in the
current code, as it sends PM_POST_RESTORE instead of
PM_POST_HIBERNATION wrongly.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;

</content>
</entry>
<entry>
<title>mmc: atmel-mci: fix multiblock SDIO transfers</title>
<updated>2011-02-06T19:03:47+00:00</updated>
<author>
<name>Nicolas Ferre</name>
<email>nicolas.ferre@atmel.com</email>
</author>
<published>2010-12-10T18:14:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3fa84c1cbf8baca625f08f475338193ee9be1eea'/>
<id>urn:sha1:3fa84c1cbf8baca625f08f475338193ee9be1eea</id>
<content type='text'>
commit 2f1d791882d21a4002a719fb016a1ac21c8bd6b7 upstream.

Based on report made by Yauhen in:
"MMC: Fix multiblock SDIO transfers in AT91 MCI" patch,
I report those changes to the brother driver: atmel-mci.

So, this patch sets SDIO transfer types: SDIO block and SDIO byte
transfers instead of using ordinary MMC block transfers.
It is checking opcode for SDIO CMD53 and setting transfer
type in MCI_CMDR register properly.

Reported-by: Yauhen Kharuzhy &lt;yauhen.kharuzhy@promwad.com&gt;
Signed-off-by: Nicolas Ferre &lt;nicolas.ferre@atmel.com&gt;
Acked-by: Jean-Christophe PLAGNIOL-VILLARD &lt;plagnioj@jcrosoft.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;

</content>
</entry>
<entry>
<title>mmc: at91_mci: fix multiblock SDIO transfers</title>
<updated>2011-02-06T19:03:47+00:00</updated>
<author>
<name>Yauhen Kharuzhy</name>
<email>yauhen.kharuzhy@promwad.com</email>
</author>
<published>2010-11-25T10:11:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=84da397234ceec8449444598d8d72668d7f5bb8c'/>
<id>urn:sha1:84da397234ceec8449444598d8d72668d7f5bb8c</id>
<content type='text'>
commit a2255ff45143001fecbc5e5a4b58fcb999d393ae upstream.

The AT91 MCI has special SDIO transfer types: SDIO block and SDIO byte
transfers, but at91_mci driver doesn't use them and handles all SDIO
transfers as ordinary MMC block transfers. This causes problems for
multiple-block SDIO transfers (in particular for 256-bytes blocks).

Fix this situation by checking the opcode for SDIO CMD53 and setting
the transfer type in the AT91_MCI_CMDR register properly.

This patch was tested with libertas SDIO driver: problem with TX
timeouts on big packets was eliminated.

Signed-off-by: Yauhen Kharuzhy &lt;yauhen.kharuzhy@promwad.com&gt;
Signed-off-by: Nicolas Ferre &lt;nicolas.ferre@atmel.com&gt;
Acked-by: Jean-Christophe PLAGNIOL-VILLARD &lt;plagnioj@jcrosoft.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;

</content>
</entry>
<entry>
<title>mmc: fix rmmod race for hosts using card-detection polling</title>
<updated>2010-12-14T22:40:15+00:00</updated>
<author>
<name>Guennadi Liakhovetski</name>
<email>g.liakhovetski@gmx.de</email>
</author>
<published>2010-11-11T16:32:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=79ec0bc0601b3c1bce4457361ec9d477b7982480'/>
<id>urn:sha1:79ec0bc0601b3c1bce4457361ec9d477b7982480</id>
<content type='text'>
commit d9bcbf343ec63e1104b5276195888ee06b4d086f upstream.

MMC hosts that poll for card detection by defining the MMC_CAP_NEEDS_POLL
flag have a race on rmmod, where the delayed work is cancelled without
waiting for completed polling. To prevent this a _sync version of the work
cancellation has to be used.

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@suse.de&gt;
Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;

</content>
</entry>
<entry>
<title>mmc: sdio: fix SDIO suspend/resume regression</title>
<updated>2010-10-29T04:51:34+00:00</updated>
<author>
<name>Ohad Ben-Cohen</name>
<email>ohad@wizery.com</email>
</author>
<published>2010-10-13T07:31:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=63cb57e4d31311bf80639d07ba006d39651304bb'/>
<id>urn:sha1:63cb57e4d31311bf80639d07ba006d39651304bb</id>
<content type='text'>
commit 1c8cf9c997a4a6b36e907c7ede5f048aeaab1644 upstream.

Fix SDIO suspend/resume regression introduced by 4c2ef25fe0b "mmc: fix
all hangs related to mmc/sd card insert/removal during suspend/resume":

  PM: Syncing filesystems ... done.
  Freezing user space processes ... (elapsed 0.01 seconds) done.
  Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
  Suspending console(s) (use no_console_suspend to debug)
  pm_op(): platform_pm_suspend+0x0/0x5c returns -38
  PM: Device pxa2xx-mci.0 failed to suspend: error -38
  PM: Some devices failed to suspend

4c2ef25fe0b moved the card removal/insertion mechanism out of MMC's
suspend/resume path and into pm notifiers (mmc_pm_notify), and that
broke SDIO's expectation that mmc_suspend_host() will remove the card,
and squash the error, in case -ENOSYS is returned from the bus suspend
handler (mmc_sdio_suspend() in this case).

mmc_sdio_suspend() is using this whenever at least one of the card's SDIO
function drivers does not have suspend/resume handlers - in that case
it is agreed to force removal of the entire card.

This patch fixes this regression by trivially bringing back that part of
mmc_suspend_host(), which was removed by 4c2ef25fe0b.

Reported-and-tested-by: Sven Neumann &lt;s.neumann@raumfeld.com&gt;
Signed-off-by: Ohad Ben-Cohen &lt;ohad@wizery.com&gt;
Cc: Maxim Levitsky &lt;maximlevitsky@gmail.com&gt;
Acked-by: Nicolas Pitre &lt;nico@fluxnic.net&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-s3c: fix NULL ptr access in sdhci_s3c_remove</title>
<updated>2010-10-29T04:51:14+00:00</updated>
<author>
<name>Marek Szyprowski</name>
<email>m.szyprowski@samsung.com</email>
</author>
<published>2010-09-23T14:22:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0afe0f1ae5a0c79c690e4f3738ab82613aef5441'/>
<id>urn:sha1:0afe0f1ae5a0c79c690e4f3738ab82613aef5441</id>
<content type='text'>
commit 9320f7cbbdd5febf013b0e91db29189724057738 upstream.

If not all clocks have been defined in platform data, the driver will
cause a null pointer dereference when it is removed. This patch fixes
this issue.

Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
</feed>
