linux.git/drivers/mmc/core, branch v4.16

mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards

2018-03-15T09:50:59+00:00

Certain Micron eMMC v4.5 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.

In U-Boot, these cards are reported as

Manufacturer: Micron (ID: 0xFE)
OEM: 0x4E
Name: MMC32G
Revision: 19 (0x13)
Serial: 959241022  Manufact. date: 8/2015 (0x82)  CRC: 0x00
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 29.1 GiB
Boot Partition Size: 16 MiB
Bus Width: 8-bit

According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by
Micron.

Signed-off-by: Dirk Behme 
Signed-off-by: Mark Craske 
Cc:  # 4.8+
Signed-off-by: Ulf Hansson

mmc: block: fix updating ext_csd caches on ioctl call

2018-03-15T09:31:38+00:00

PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the
currently active partition in mmc_blk_data->part_curr. These caches do
not always reflect changes if the ioctl call modifies the
PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE.

Write the PARTITION_CONFIG value extracted from the ioctl call to the
cache and update the currently active partition accordingly. This
ensures that the user space cannot change the values behind the
kernel's back. The next call to mmc_blk_part_switch() will operate on
the data set by the ioctl and reflect the changes appropriately.

Signed-off-by: Bastian Stender 
Signed-off-by: Jan Luebbe 
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson

mmc: core: Avoid hanging to claim host for mmc via some nested calls

2018-02-27T14:12:37+00:00

As the block layer, since the conversion to blkmq, claims the host using a
context, a following nested call to mmc_claim_host(), which isn't using a
context, may hang.

Calling mmc_interrupt_hpi() and mmc_read_bkops_status() via the mmc block
layer, may suffer from this problem, as these functions are calling
mmc_claim|release_host().

Let's fix the problem by removing the calls to mmc_claim|release_host()
from the above mentioned functions and instead make the callers responsible
of claiming/releasing the host. As a matter of fact, the existing callers
already deals with it.

Fixes: 81196976ed94 ("mmc: block: Add blk-mq support")
Reported-by: Dmitry Osipenko 
Suggested-by: Adrian Hunter 
Tested-by: Dmitry Osipenko 
Signed-off-by: Ulf Hansson 
Acked-by: Adrian Hunter 
Reviewed-by: Shawn Lin

mmc: slot-gpio: add a helper to check capability of GPIO WP detection

2018-01-18T08:08:56+00:00

Like mmc_can_gpio_cd(), mmc_can_gpio_ro() will also be useful for host
drivers to know whether GPIO write-protect detection is supported.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Ulf Hansson

mmc: block: fix logical error to avoid memory leak

2017-12-18T13:02:16+00:00

If the MMC_DRV_OP_GET_EXT_CSD request completes successfully, then
ext_csd must be freed, but in one case it was not. Fix that.

Signed-off-by: Liu Changcheng 
Acked-by: Adrian Hunter 
Acked-by: Linus Walleij 
Signed-off-by: Ulf Hansson

mmc: avoid removing non-removable hosts during suspend

2017-12-18T12:56:59+00:00

The Weibu F3C MiniPC has an onboard AP6255 module, presenting
two SDIO functions on a single MMC host (Bluetooth/btsdio and
WiFi/brcmfmac), and the mmc layer correctly detects this as
non-removable.

After suspend/resume, the wifi and bluetooth interfaces disappear
and do not get probed again.

The conditions here are:

 1. During suspend, we reach mmc_pm_notify()

 2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
    suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
    -ENOSYS because btsdio_driver does not have a suspend method.

 3. mmc_pm_notify() proceeds to remove the card

 4. Upon resume, mmc_rescan() does nothing with this host, because of
    the rescan_entered check which aims to only scan a non-removable
    device a single time (i.e. during boot).

Fix the loss of functionality by detecting that we are unable to
suspend a non-removable host, so avoid the forced removal in that
case. The comment above this function already indicates that this
code was only intended for removable devices.

Signed-off-by: Daniel Drake 
Signed-off-by: Ulf Hansson

Merge branch 'fixes' into next

2017-12-11T12:56:08+00:00

mmc: core: apply NO_CMD23 quirk to some specific cards

2017-12-11T12:43:27+00:00

To get an usdhc Apacer and some ATP SD cards work reliable, CMD23 needs
to be disabled.  This has been tested on i.MX6 (sdhci-esdhc) and rk3288
(dw_mmc-rockchip).

Without this patch on i.MX6 (sdhci-esdhc):

 $ dd if=/dev/urandom of=/mnt/test bs=1M count=10 conv=fsync

    | 
    | mmc0: starting CMD25 arg 00a71f00 flags 000000b5
    | mmc0:     blksz 512 blocks 1024 flags 00000100 tsac 3000 ms nsac 0
    | mmc0:     CMD12 arg 00000000 flags 0000049d
    | sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
    | mmc0: Timeout waiting for hardware interrupt.

Without this patch on rk3288 (dw_mmc-rockchip):

    | mmc1: Card stuck in programming state! mmcblk1 card_busy_detect
    | dwmmc_rockchip ff0c0000.dwmmc: Busy; trying anyway
    | mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz,
    | actual 400000HZ div = 0)
    | mmc1: card never left busy state
    | mmc1: tried to reset card, got error -110
    | blk_update_request: I/O error, dev mmcblk1, sector 139778
    | Buffer I/O error on dev mmcblk1p1, logical block 131586, lost async
    | page write

Signed-off-by: Christoph Fritz 
Cc:  # v4.14+
Signed-off-by: Ulf Hansson

Merge branch 'fixes' into next

2017-12-11T12:19:35+00:00

mmc: block: blk-mq: Potential NULL deref on mmc_blk_alloc_req() failure

2017-12-11T12:13:38+00:00

mmc_blk_alloc_req() is supposed to return error pointers but there is
one path where we forget to set the error code and accidentally return
NULL.  The callers are not expecting that and will have a NULL pointer
dereference.

Fixes: 41e3efd07d5a ("mmc: block: Simplify cleaning up the queue")
Signed-off-by: Dan Carpenter 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson