kernel/drivers/mmc/core, branch linux-5.1.y

mmc: core: complete HS400 before checking status

2019-07-14T06:09:44Z

[ Upstream commit b0e370b95a3b231d0fb5d1958cce85ef57196fe6 ] We don't have a reproducible error case, yet our BSP team suggested that the mmc_switch_status() command in mmc_select_hs400() should come after the callback into the driver completing HS400 setup. It makes sense to me because we want the status of a fully setup HS400, so it will increase the reliability of the mmc_switch_status() command. Reported-by: Yoshihiro Shimoda Signed-off-by: Wolfram Sang Fixes: ba6c7ac3a2f4 ("mmc: core: more fine-grained hooks for HS400 tuning") Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: core: Prevent processing SDIO IRQs when the card is suspended

2019-06-25T03:34:44Z

commit 83293386bc95cf5e9f0c0175794455835bd1cb4a upstream. Processing of SDIO IRQs must obviously be prevented while the card is system suspended, otherwise we may end up trying to communicate with an uninitialized SDIO card. Reports throughout the years shows that this is not only a theoretical problem, but a real issue. So, let's finally fix this problem, by keeping track of the state for the card and bail out before processing the SDIO IRQ, in case the card is suspended. Cc: stable@vger.kernel.org Reported-by: Douglas Anderson Tested-by: Douglas Anderson Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()

2019-06-25T03:34:44Z

commit b4c9f938d542d5f88c501744d2d12fad4fd2915f upstream. We want SDIO drivers to be able to temporarily stop retuning when the driver knows that the SDIO card is not in a state where retuning will work (maybe because the card is asleep). We'll move the relevant functions to a place where drivers can call them. Cc: stable@vger.kernel.org #v4.18+ Signed-off-by: Douglas Anderson Acked-by: Adrian Hunter Acked-by: Kalle Valo Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: API to temporarily disable retuning for SDIO CRC errors

2019-06-25T03:34:44Z

commit 0a55f4ab9678413a01e740c86e9367ba0c612b36 upstream. Normally when the MMC core sees an "-EILSEQ" error returned by a host controller then it will trigger a retuning of the card. This is generally a good idea. However, if a command is expected to sometimes cause transfer errors then these transfer errors shouldn't cause a re-tuning. This re-tuning will be a needless waste of time. One example case where a transfer is expected to cause errors is when transitioning between idle (sometimes referred to as "sleep" in Broadcom code) and active state on certain Broadcom WiFi SDIO cards. Specifically if the card was already transitioning between states when the command was sent it could cause an error on the SDIO bus. Let's add an API that the SDIO function drivers can call that will temporarily disable the auto-tuning functionality. Then we can add a call to this in the Broadcom WiFi driver and any other driver that might have similar needs. NOTE: this makes the assumption that the card is already tuned well enough that it's OK to disable the auto-retuning during one of these error-prone situations. Presumably the driver code performing the error-prone transfer knows how to recover / retry from errors. ...and after we can get back to a state where transfers are no longer error-prone then we can enable the auto-retuning again. If we truly find ourselves in a case where the card needs to be retuned sometimes to handle one of these error-prone transfers then we can always try a few transfers first without auto-retuning and then re-try with auto-retuning if the first few fail. Without this change on rk3288-veyron-minnie I periodically see this in the logs of a machine just sitting there idle: dwmmc_rockchip ff0d0000.dwmmc: Successfully tuned phase to XYZ Cc: stable@vger.kernel.org #v4.18+ Signed-off-by: Douglas Anderson Acked-by: Adrian Hunter Acked-by: Kalle Valo Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: make pwrseq_emmc (partially) support sleepy GPIO controllers

2019-05-31T13:43:33Z

[ Upstream commit 002ee28e8b322d4d4b7b83234b5d0f4ebd428eda ] pwrseq_emmc.c implements a HW reset procedure for eMMC chip by driving a GPIO line. It registers the .reset() cb on mmc_pwrseq_ops and it registers a system restart notification handler; both of them perform reset by unconditionally calling gpiod_set_value(). If the eMMC reset line is tied to a GPIO controller whose driver can sleep (i.e. I2C GPIO controller), then the kernel would spit warnings when trying to reset the eMMC chip by means of .reset() mmc_pwrseq_ops cb (that is exactly what I'm seeing during boot). Furthermore, on system reset we would gets to the system restart notification handler with disabled interrupts - local_irq_disable() is called in machine_restart() at least on ARM/ARM64 - and we would be in trouble when the GPIO driver tries to sleep (which indeed doesn't happen here, likely because in my case the machine specific code doesn't call do_kernel_restart(), I guess..). This patch fixes the .reset() cb to make use of gpiod_set_value_cansleep(), so that the eMMC gets reset on boot without complaints, while, since there isn't that much we can do, we avoid register the restart handler if the GPIO controller has a sleepy driver (and we spit a dev_notice() message to let people know).. This had been tested on a downstream 4.9 kernel with backported commit 83f37ee7ba33 ("mmc: pwrseq: Add reset callback to the struct mmc_pwrseq_ops") and commit ae60fb031cf2 ("mmc: core: Don't do eMMC HW reset when resuming the eMMC card"), because I couldn't boot my board otherwise. Maybe worth to RFT. Signed-off-by: Andrea Merello Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: core: Verify SD bus width

2019-05-31T13:43:14Z

[ Upstream commit 9e4be8d03f50d1b25c38e2b59e73b194c130df7d ] The SD Physical Layer Spec says the following: Since the SD Memory Card shall support at least the two bus modes 1-bit or 4-bit width, then any SD Card shall set at least bits 0 and 2 (SD_BUS_WIDTH="0101"). This change verifies the card has specified a bus width. AMD SDHC Device 7806 can get into a bad state after a card disconnect where anything transferred via the DATA lines will always result in a zero filled buffer. Currently the driver will continue without error if the HC is in this condition. A block device will be created, but reading from it will result in a zero buffer. This makes it seem like the SD device has been erased, when in actuality the data is never getting copied from the DATA lines to the data buffer. SCR is the first command in the SD initialization sequence that uses the DATA lines. By checking that the response was invalid, we can abort mounting the card. Reviewed-by: Avri Altman Signed-off-by: Raul E Rangel Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: core: Fix tag set memory leak

2019-05-22T05:39:47Z

commit 43d8dabb4074cf7f3b1404bfbaeba5aa6f3e5cfc upstream. The tag set is allocated in mmc_init_queue but never freed. This results in a memory leak. This change makes sure we free the tag set when the queue is also freed. Signed-off-by: Raul E Rangel Reviewed-by: Jens Axboe Acked-by: Adrian Hunter Fixes: 81196976ed94 ("mmc: block: Add blk-mq support") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

Merge tag 'for-5.1/block-20190302' of git://git.kernel.dk/linux-block

2019-03-08T22:12:17Z

Pull block layer updates from Jens Axboe: "Not a huge amount of changes in this round, the biggest one is that we finally have Mings multi-page bvec support merged. Apart from that, this pull request contains: - Small series that avoids quiescing the queue for sysfs changes that match what we currently have (Aleksei) - Series of bcache fixes (via Coly) - Series of lightnvm fixes (via Mathias) - NVMe pull request from Christoph. Nothing major, just SPDX/license cleanups, RR mp policy (Hannes), and little fixes (Bart, Chaitanya). - BFQ series (Paolo) - Save blk-mq cpu -> hw queue mapping, removing a pointer indirection for the fast path (Jianchao) - fops->iopoll() added for async IO polling, this is a feature that the upcoming io_uring interface will use (Christoph, me) - Partition scan loop fixes (Dongli) - mtip32xx conversion from managed resource API (Christoph) - cdrom registration race fix (Guenter) - MD pull from Song, two minor fixes. - Various documentation fixes (Marcos) - Multi-page bvec feature. This brings a lot of nice improvements with it, like more efficient splitting, larger IOs can be supported without growing the bvec table size, and so on. (Ming) - Various little fixes to core and drivers" * tag 'for-5.1/block-20190302' of git://git.kernel.dk/linux-block: (117 commits) block: fix updating bio's front segment size block: Replace function name in string with __func__ nbd: propagate genlmsg_reply return code floppy: remove set but not used variable 'q' null_blk: fix checking for REQ_FUA block: fix NULL pointer dereference in register_disk fs: fix guard_bio_eod to check for real EOD errors blk-mq: use HCTX_TYPE_DEFAULT but not 0 to index blk_mq_tag_set->map block: optimize bvec iteration in bvec_iter_advance block: introduce mp_bvec_for_each_page() for iterating over page block: optimize blk_bio_segment_split for single-page bvec block: optimize __blk_segment_map_sg() for single-page bvec block: introduce bvec_nth_page() iomap: wire up the iopoll method block: add bio_set_polled() helper block: wire up block device iopoll method fs: add an iopoll method to struct file_operations loop: set GENHD_FL_NO_PART_SCAN after blkdev_reread_part() loop: do not print warn message if partition scan is successful block: bounce: make sure that bvec table is updated ...

mmc:fix a bug when max_discard is 0

2019-03-01T08:50:10Z

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

mmc: core: Add a debug print when the card may have been replaced

2019-02-28T08:28:27Z

If the card was removed in suspended state and a new one was inserted, print a debug log when the check detects that it's not the old card. Signed-off-by: hongjiefang Signed-off-by: Ulf Hansson