kernel/linux.git/drivers/mmc/core, branch v4.19.39

mmc:fix a bug when max_discard is 0

2019-03-23T19:09:57+00:00

commit d4721339dcca7def04909a8e60da43c19a24d8bf upstream. The original purpose of the code I fix is to replace max_discard with max_trim if max_trim is less than max_discard. When max_discard is 0 we should replace max_discard with max_trim as well, because max_discard equals 0 happens only when the max_do_calc_max_discard process is overflowed, so if mmc_can_trim(card) is true, max_discard should be replaced by an available max_trim. However, in the original code, there are two lines of code interfere the right process. 1) if (max_discard && mmc_can_trim(card)) when max_discard is 0, it skips the process checking if max_discard needs to be replaced with max_trim. 2) if (max_trim < max_discard) the condition is false when max_discard is 0. it also skips the process that replaces max_discard with max_trim, in fact, we should replace the 0-valued max_discard with max_trim. Signed-off-by: Jiong Wu Fixes: b305882fbc87 (mmc: core: optimize mmc_calc_max_discard) Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: Fix NULL ptr crash from mmc_should_fail_request

2019-03-05T16:58:53+00:00

commit e5723f95d6b493dd437f1199cacb41459713b32f upstream. In case of CQHCI, mrq->cmd may be NULL for data requests (non DCMD). In such case mmc_should_fail_request is directly dereferencing mrq->cmd while cmd is NULL. Fix this by checking for mrq->cmd pointer. Fixes: 72a5af554df8 ("mmc: core: Add support for handling CQE requests") Signed-off-by: Ritesh Harjani Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: block: handle complete_work on separate workqueue

2019-02-20T09:25:46+00:00

commit dcf6e2e38a1c7ccbc535de5e1d9b14998847499d upstream. The kblockd workqueue is created with the WQ_MEM_RECLAIM flag set. This generates a rescuer thread for that queue that will trigger when the CPU is under heavy load and collect the uncompleted work. In the case of mmc, this creates the possibility of a deadlock when there are multiple partitions on the device as other blk-mq work is also run on the same queue. For example: - worker 0 claims the mmc host to work on partition 1 - worker 1 attempts to claim the host for partition 2 but has to wait for worker 0 to finish - worker 0 schedules complete_work to release the host - rescuer thread is triggered after time-out and collects the dangling work - rescuer thread attempts to complete the work in order starting with claim host - the task to release host is now blocked by a task to claim it and will never be called The above results in multiple hung tasks that lead to failures to mount partitions. Handling complete_work on a separate workqueue avoids this by keeping the work completion tasks separate from the other blk-mq work. This allows the host to be released without getting blocked by other tasks attempting to claim the host. Signed-off-by: Zachary Hays Fixes: 81196976ed94 ("mmc: block: Add blk-mq support") Cc: Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrl

2018-12-29T12:37:56+00:00

commit e3ae3401aa19432ee4943eb0bbc2ec704d07d793 upstream. Some eMMCs from Micron have been reported to need ~800 ms timeout, while enabling the CACHE ctrl after running sudden power failure tests. The needed timeout is greater than what the card specifies as its generic CMD6 timeout, through the EXT_CSD register, hence the problem. Normally we would introduce a card quirk to extend the timeout for these specific Micron cards. However, due to the rather complicated debug process needed to find out the error, let's simply use a minimum timeout of 1600ms, the double of what has been reported, for all cards when enabling CACHE ctrl. Reported-by: Sjoerd Simons Reported-by: Andreas Dannenberg Reported-by: Faiz Abbas Cc: Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: Allow BKOPS and CACHE ctrl even if no HPI support

2018-12-29T12:37:55+00:00

commit ba9f39a785a9977e72233000711ef1eb48203551 upstream. In commit 5320226a0512 ("mmc: core: Disable HPI for certain Hynix eMMC cards"), then intent was to prevent HPI from being used for some eMMC cards, which didn't properly support it. However, that went too far, as even BKOPS and CACHE ctrl became prevented. Let's restore those parts and allow BKOPS and CACHE ctrl even if HPI isn't supported. Fixes: 5320226a0512 ("mmc: core: Disable HPI for certain Hynix eMMC cards") Cc: Pratibhasagar V Cc: Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: Reset HPI enabled state during re-init and in case of errors

2018-12-29T12:37:55+00:00

commit a0741ba40a009f97c019ae7541dc61c1fdf41efb upstream. During a re-initialization of the eMMC card, we may fail to re-enable HPI. In these cases, that isn't properly reflected in the card->ext_csd.hpi_en bit, as it keeps being set. This may cause following attempts to use HPI, even if's not enabled. Let's fix this! Fixes: eb0d8f135b67 ("mmc: core: support HPI send command") Cc: Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: use mrq->sbc when sending CMD23 for RPMB

2018-12-19T18:19:51+00:00

commit a44f7cb937321d4961bfc8f28912126b06e701c5 upstream. When sending out CMD23 in the blk preparation, the comment there rightfully says: * However, it is not sufficient to just send CMD23, * and avoid the final CMD12, as on an error condition * CMD12 (stop) needs to be sent anyway. This, coupled * with Auto-CMD23 enhancements provided by some * hosts, means that the complexity of dealing * with this is best left to the host. If CMD23 is * supported by card and host, we'll fill sbc in and let * the host deal with handling it correctly. Let's do this behaviour for RPMB as well, and not send CMD23 independently. Otherwise IP cores (like Renesas SDHI) may timeout because of automatic CMD23/CMD12 handling. Reported-by: Masaharu Hayakawa Signed-off-by: Wolfram Sang Tested-by: Clément Péron Reviewed-by: Avri Altman Reviewed-by: Niklas Söderlund Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: block: avoid multiblock reads for the last sector in SPI mode

2018-10-09T07:23:00+00:00

On some SD cards over SPI, reading with the multiblock read command the last sector will leave the card in a bad state. Remove last sectors from the multiblock reading cmd. Signed-off-by: Chris Boot Signed-off-by: Clément Péron Cc: stable@vger.kernel.org # v4.10+ Signed-off-by: Ulf Hansson

mmc: slot-gpio: Fix debounce time to use miliseconds again

2018-09-28T15:43:48+00:00

The debounce value passed to mmc_gpiod_request_cd() function is in microseconds, but msecs_to_jiffies() requires the value to be in miliseconds to properly calculate the delay, so adjust the value stored in cd_debounce_delay_ms context entry. Fixes: 1d71926bbd59 ("mmc: core: Fix debounce time to use microseconds") Fixes: bfd694d5e21c ("mmc: core: Add tunable delay before detecting card after card is inserted") Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Marek Szyprowski Reviewed-by: Linus Walleij Signed-off-by: Ulf Hansson

mmc: core: Fix debounce time to use microseconds

2018-09-26T22:39:32+00:00

The debounce value in device tree is in milliseconds but needs to be in microseconds for mmc_gpiod_request_cd(). Fixes: bfd694d5e21c ("mmc: core: Add tunable delay before detecting card after card is inserted") Cc: Shawn Lin Signed-off-by: Tony Lindgren Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Ulf Hansson