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

mmc: sdhci-pci-o2micro: Fix Dell E5440 issue

2015-01-08T18:27:45+00:00

commit 6380ea099cdd46d7377b6fbec0291cf2aa387bad upstream.

Fix Dell E5440 when reboot Linux, can't find o2micro sd host chip issue.

Fixes: 01acf6917aed (mmc: sdhci-pci: add support of O2Micro/BayHubTech SD hosts)
Signed-off-by: Peter Guo 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: block: add newline to sysfs display of force_ro

2015-01-08T18:27:45+00:00

commit 0031a98a85e9fca282624bfc887f9531b2768396 upstream.

Make force_ro consistent with other sysfs entries.

Fixes: 371a689f64b0d ('mmc: MMC boot partitions support')
Cc: Andrei Warkentin 
Signed-off-by: Baruch Siach 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: omap_hsmmc: Fix UHS card with DDR50 support

2015-01-08T18:27:45+00:00

commit 903101a83949d6fc77c092cef07e9c1e10c07e46 upstream.

The commit, mmc: omap: clarify DDR timing mode between SD-UHS and eMMC,
switched omap_hsmmc to support MMC DDR mode instead of UHS DDR50 mode.

Add UHS DDR50 mode again and this time let's also keep the MMC DDR mode.

Fixes: 5438ad95a57c (mmc: omap: clarify DDR timing mode between SD-UHS and eMMC)
Reported-by: Kishon Vijay Abraham I 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: avoid write to CDTHRCTL on older versions

2015-01-08T18:27:45+00:00

commit 66dfd10173159cafa9cb0d39936b8daeaab8e3e0 upstream.

Commit f1d2736c8156 (mmc: dw_mmc: control card read threshold) added
dw_mci_ctrl_rd_thld() with an unconditional write to the CDTHRCTL
register at offset 0x100. However before version 240a, the FIFO region
started at 0x100, so the write messes with the FIFO and completely
breaks the driver.

If the version id < 240A, return early from dw_mci_ctl_rd_thld() so as
not to hit this problem.

Fixes: f1d2736c8156 (mmc: dw_mmc: control card read threshold)
Signed-off-by: James Hogan 
Acked-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-s3c: fix runtime PM handling on sdhci_add_host() failure

2014-11-14T18:10:23+00:00

commit 221414db1934c1c883501998f510bb75acfbaa51 upstream.

Runtime Power Management handling for the sdhci_add_host() failure
case in sdhci_s3c_probe() should match the code in sdhci_s3c_remove()
(which uses pm_runtime_disable() call which matches the earlier
pm_runtime_enable() one).  Fix it.

This patch fixes "BUG: spinlock bad magic on CPU#0, swapper/0/1" and
"Unbalanced pm_runtime_enable!" warnings.

>From the kernel log:
...
[    1.659631] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
[    1.665096] BUG: spinlock bad magic on CPU#0, swapper/0/1
[    1.670433]  lock: 0xea01e484, .magic: 00000000, .owner: /-1, .owner_cpu: 0
[    1.677895] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-next-20140804-00008-ga59480f-dirty #707
[    1.687037] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[    1.694740] [] (show_stack) from [] (dump_stack+0x68/0xb8)
[    1.701948] [] (dump_stack) from [] (do_raw_spin_lock+0x15c/0x1a4)
[    1.709848] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x20/0x28)
[    1.718619] [] (_raw_spin_lock_irqsave) from [] (sdhci_do_set_ios+0x1c/0x5cc)
[    1.727464] [] (sdhci_do_set_ios) from [] (sdhci_runtime_resume_host+0x50/0x104)
[    1.736574] [] (sdhci_runtime_resume_host) from [] (pm_generic_runtime_resume+0x2c/0x40)
[    1.746383] [] (pm_generic_runtime_resume) from [] (__rpm_callback+0x34/0x70)
[    1.755233] [] (__rpm_callback) from [] (rpm_callback+0x28/0x88)
[    1.762958] [] (rpm_callback) from [] (rpm_resume+0x384/0x4ec)
[    1.770511] [] (rpm_resume) from [] (pm_runtime_forbid+0x58/0x64)
[    1.778325] [] (pm_runtime_forbid) from [] (sdhci_s3c_probe+0x4a4/0x540)
[    1.786749] [] (sdhci_s3c_probe) from [] (platform_drv_probe+0x2c/0x5c)
[    1.795076] [] (platform_drv_probe) from [] (driver_probe_device+0x114/0x234)
[    1.803929] [] (driver_probe_device) from [] (__driver_attach+0x8c/0x90)
[    1.812347] [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
[    1.820506] [] (bus_for_each_dev) from [] (bus_add_driver+0xd8/0x1cc)
[    1.828665] [] (bus_add_driver) from [] (driver_register+0x78/0xf4)
[    1.836652] [] (driver_register) from [] (do_one_initcall+0x80/0x1d0)
[    1.844816] [] (do_one_initcall) from [] (kernel_init_freeable+0x108/0x1d4)
[    1.853503] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4)
[    1.861568] [] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
[    1.869582] platform 12530000.sdhci: Driver s3c-sdhci requests probe deferral
...
[    1.997047] s3c-sdhci 12530000.sdhci: Unbalanced pm_runtime_enable!
...
[    2.027235] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
[    2.032884] platform 12530000.sdhci: Driver s3c-sdhci requests probe deferral
...

Tested on Hardkernel's Exynos4412 based ODROID-U3 board.

Fixes: 9f4e8151dbbc ("mmc: sdhci-s3c: Enable runtime power management")
Cc: Mark Brown 
Cc: Jaehoon Chung 
Cc: Ben Dooks 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Acked-by: Kyungmin Park 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response

2014-11-14T18:10:23+00:00

commit d1419d50c1bf711e9fd27b516a739c86b23f7cf9 upstream.

Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.

Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.

Fixes: ff984e57d36e ("mmc: Add realtek pcie sdmmc host driver")
Signed-off-by: Roger Tseng 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: don't request CD IRQ until mmc_start_host()

2014-11-14T18:10:22+00:00

commit d4d11449088ee9aca16fd1884b852b8b73a4bda1 upstream.

As soon as the CD IRQ is requested, it can trigger, since it's an
externally controlled event. If it does, delayed_work host->detect will
be scheduled.

Many host controller probe()s are roughly structured as:

*_probe() {
    host = sdhci_pltfm_init();
    mmc_of_parse(host->mmc);
    rc = sdhci_add_host(host);
    if (rc) {
        sdhci_pltfm_free();
        return rc;
    }

In 3.17, CD IRQs can are enabled quite early via *_probe() ->
mmc_of_parse() -> mmc_gpio_request_cd() -> mmc_gpiod_request_cd_irq().

Note that in linux-next, mmc_of_parse() calls mmc_gpio*d*_request_cd()
rather than mmc_gpio_request_cd(), and mmc_gpio*d*_request_cd() doesn't
call mmc_gpiod_request_cd_irq(). However, this issue still exists if
mmc_gpio_request_cd() is called directly before mmc_start_host().

sdhci_add_host() may fail part way through (e.g. due to deferred
probe for a vmmc regulator), and sdhci_pltfm_free() does nothing to
unrequest the CD IRQ nor cancel the delayed_work. sdhci_pltfm_free() is
coded to assume that if sdhci_add_host() failed, then the delayed_work
cannot (or should not) have been triggered.

This can lead to the following with CONFIG_DEBUG_OBJECTS_* enabled, when
kfree(host) is eventually called inside sdhci_pltfm_free():

WARNING: CPU: 2 PID: 6 at lib/debugobjects.c:263 debug_print_object+0x8c/0xb4()
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x18

The object being complained about is host->detect.

There's no need to request the CD IRQ so early; mmc_start_host() already
requests it. For most SDHCI hosts at least, the typical call path that
does this is: *_probe() -> sdhci_add_host() -> mmc_add_host() ->
mmc_start_host(). Therefore, remove the call to mmc_gpiod_request_cd_irq()
from mmc_gpio_request_cd(). This also matches mmc_gpio*d*_request_cd(),
which already doesn't call mmc_gpiod_request_cd_irq().

However, some host controller drivers call mmc_gpio_request_cd() after
mmc_start_host() has already been called, and assume that this will also
call mmc_gpiod_request_cd_irq(). Update those drivers to explicitly call
mmc_gpiod_request_cd_irq() themselves. Ideally, these drivers should be
modified to move their call to mmc_gpio_request_cd() before their call
to mmc_add_host(). However that's too large a change for stable.

This solves the problem (eliminates the kernel error message above),
since it guarantees that the IRQ can't trigger before mmc_start_host()
is called.

The critical point here is that once sdhci_add_host() calls
mmc_add_host() -> mmc_start_host(), sdhci_add_host() is coded not to
fail. In other words, if there's a chance that mmc_start_host() may have
been called, and CD IRQs triggered, and the delayed_work scheduled,
sdhci_add_host() won't fail, and so cleanup is no longer via
sdhci_pltfm_free() (which doesn't free the IRQ or cancel the work queue)
but instead must be via sdhci_remove_host(), which calls mmc_remove_host()
-> mmc_stop_host(), which does free the IRQ and cancel the work queue.

CC: Russell King 
Cc: Adrian Hunter 
Cc: Alexandre Courbot 
Cc: Linus Walleij 
Signed-off-by: Stephen Warren 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response

2014-11-14T18:10:22+00:00

commit 6f67cc6fd1cf339a0f19b9d4a998ec3c0123b1b6 upstream.

Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.

Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.

Fixes: c7f6558d84af ("mmc: Add realtek USB sdmmc host driver")
Signed-off-by: Roger Tseng 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-pxav3: set_uhs_signaling is initialized twice differently

2014-11-14T18:10:22+00:00

commit b315376573778b195e640a163675fb9f5937ddca upstream.

.set_uhs_signaling field is currently initialised twice once to the
arch specific callback pxav3_set_uhs_signaling, and also to the generic
sdhci_set_uhs_signaling callback.

This means that uhs is currently broken for this platform currently, as pxav3
has some special constriants which means it can't use the generic callback.

This happened in
commit 96d7b78cfc2f ("mmc: sdhci: convert sdhci_set_uhs_signaling() into a library function")
commit a702c8abb2a9 ("mmc: host: split up sdhci-pxa, create sdhci-pxav3.c")'

Fix this and hopefully prevent it happening in the future by ensuring named
initialisers always follow the declaration order in the structure definition.

Signed-off-by: Peter Griffin 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: core: sdio: Fix unconditional wake_up_process() on sdio thread

2014-11-14T18:10:22+00:00

commit dea67c4ec8218b301d7cac7ee6e63dac0bc566cb upstream.

781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
the use of our own custom threaded IRQ handler, but left in an
unconditional wake_up_process() on that handler at resume-time.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=80151

In addition, the check for MMC_CAP_SDIO_IRQ capability is added
before enable sdio IRQ.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Chris Ball 
Signed-off-by: Fu Zhonghui 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman