linux-stable.git/drivers/mmc, branch linux-2.6.27.y

mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finish

2012-02-11T14:37:15+00:00

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 
Signed-off-by: Chris Ball 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

mmc: sdhci: Check mrq->cmd in sdhci_tasklet_finish

2012-02-11T14:37:14+00:00

commit b7b4d3426d2b5ecab21578eb20d8e456a1aace8f upstream.

It seems that under certain circumstances that the sdhci_tasklet_finish()
call can be entered with mrq->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 
Signed-off-by: Mark Brown 
Signed-off-by: Chris Ball 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

mmc: sdhci-pci: Fix error case in sdhci_pci_probe_slot()

2012-02-11T14:37:13+00:00

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->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 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

sdhci: fix led naming

2009-03-17T00:52:57+00:00

commit 5dbace0c9ba110c1a3810a89fa6bf12b7574b5a3 upstream.

Fix the led device naming for the sdhci driver.

The led class documentation defines the led name to have the
form "devicename:colour:function" while not applicable sections
should be left blank.

To comply with the documentation the led device name is changed
from "mmc*" to "mmc*::".

Signed-off-by: Helmut Schaa 
Signed-off-by: Pierre Ossman 
Signed-off-by: Greg Kroah-Hartman

mmc_test: fix basic read test

2009-03-17T00:52:54+00:00

commit 58a5dd3e0e77029d3db1f8fa75d0b54b38169d5d upstream.

Due to a typo in the Basic Read test, it's currently identical to the
Basic Write test.  Fix this.

Signed-off-by: Rabin Vincent 
Signed-off-by: Pierre Ossman 
Signed-off-by: Greg Kroah-Hartman

mmc: s3cmci: fix s3c2410_dma_config() arguments.

2009-03-17T00:52:54+00:00

commit 7c48ed3383bfb2106694807361ec187fe8a4333d upstream.

The s3cmci driver is calling s3c2410_dma_config with incorrect data for
the DCON register.  The S3C2410_DCON_HWTRIG is implicit in the channel
configuration and the device selection of S3C2410_DCON_CH0_SDI is
incorrect as the DMA system may not select channel 0.

Signed-off-by: Ben Dooks 
Acked-by: Pierre Ossman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mmc: increase SD write timeout for crappy cards

2008-11-13T17:56:04+00:00

commit 493890e75d98810a3470b4aae23be628ee5e9667 upstream.

It seems that some cards are slightly out of spec and occasionally
will not be able to complete a write in the alloted 250 ms [1].
Incease the timeout slightly to allow even these cards to function
properly.

[1] http://lkml.org/lkml/2008/9/23/390

Signed-off-by: Pierre Ossman 
Signed-off-by: Greg Kroah-Hartman

atmel-mci: Initialize BLKR before sending data transfer command

2008-10-06T21:26:24+00:00

The atmel-mci driver sometimes fails data transfers like this:

   mmcblk0: error -5 transferring data
   end_request: I/O error, dev mmcblk0, sector 2749769
   end_request: I/O error, dev mmcblk0, sector 2749777

It turns out that this might be caused by the BLKR register (which
contains the block size and the number of blocks being transfered) being
initialized too late. This patch moves the initialization of BLKR so
that it contains the correct value before the block transfer command is
sent.

This error is difficult to reproduce, but if you insert a long delay
(mdelay(10) or thereabouts) between the calls to atmci_start_command()
and atmci_submit_data(), all transfers seem to fail without this patch,
while I haven't seen any failures with this patch.

Reported-by: Hein_Tibosch 
Signed-off-by: Haavard Skinnemoen 
Signed-off-by: Pierre Ossman 
Signed-off-by: Linus Torvalds

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc

2008-09-21T19:38:45+00:00

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc:
  mmc_test: initialize mmc_test_lock statically
  mmc_block: handle error from mmc_register_driver()
  atmel-mci: Set MMC_CAP_NEEDS_POLL if no detect_pin
  atmel-mci: Fix bogus debugfs file size
  atmel-mci: Fix memory leak in atmci_regs_show
  atmel-mci: debugfs: enable clock before dumping regs
  tmio_mmc: fix compilation with debug enabled

mmc_test: initialize mmc_test_lock statically

2008-09-20T11:03:50+00:00

The mutex mmc_test_lock is initialized at every time mmc_test device
is probed. Probing another mmc_test device may break the mutex, if
the probe function is called while the mutex is locked.

This patch fixes it by statically initializing mmc_test_lock.

Signed-off-by: Akinobu Mita 
Signed-off-by: Pierre Ossman