summaryrefslogtreecommitdiffstats
path: root/drivers/mmc/core
Commit message (Collapse)AuthorAgeFilesLines
* mmc: sdio: Use mmc_pre_req() / mmc_post_req()Adrian Hunter2020-09-071-17/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SDHCI changed from using a tasklet to finish requests, to using an IRQ thread i.e. commit c07a48c2651965 ("mmc: sdhci: Remove finish_tasklet"). Because this increased the latency to complete requests, a preparatory change was made to complete the request from the IRQ handler if possible i.e. commit 19d2f695f4e827 ("mmc: sdhci: Call mmc_request_done() from IRQ handler if possible"). That alleviated the situation for MMC block devices because the MMC block driver makes use of mmc_pre_req() and mmc_post_req() so that successful requests are completed in the IRQ handler and any DMA unmapping is handled separately in mmc_post_req(). However SDIO was still affected, and an example has been reported with up to 20% degradation in performance. Looking at SDIO I/O helper functions, sdio_io_rw_ext_helper() appeared to be a possible candidate for making use of asynchronous requests within its I/O loops, but analysis revealed that these loops almost never iterate more than once, so the complexity of the change would not be warrented. Instead, mmc_pre_req() and mmc_post_req() are added before and after I/O submission (mmc_wait_for_req) in mmc_io_rw_extended(). This still has the potential benefit of reducing the duration of interrupt handlers, as well as addressing the latency issue for SDHCI. It also seems a more reasonable solution than forcing drivers to do everything in the IRQ handler. Reported-by: Dmitry Osipenko <digetx@gmail.com> Fixes: c07a48c2651965 ("mmc: sdhci: Remove finish_tasklet") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200903082007.18715-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva2020-08-231-1/+1
| | | | | | | | | | Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
* Merge tag 'sched-fifo-2020-08-04' of ↵Linus Torvalds2020-08-061-2/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull sched/fifo updates from Ingo Molnar: "This adds the sched_set_fifo*() encapsulation APIs to remove static priority level knowledge from non-scheduler code. The three APIs for non-scheduler code to set SCHED_FIFO are: - sched_set_fifo() - sched_set_fifo_low() - sched_set_normal() These are two FIFO priority levels: default (high), and a 'low' priority level, plus sched_set_normal() to set the policy back to non-SCHED_FIFO. Since the changes affect a lot of non-scheduler code, we kept this in a separate tree" * tag 'sched-fifo-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (24 commits) sched,tracing: Convert to sched_set_fifo() sched: Remove sched_set_*() return value sched: Remove sched_setscheduler*() EXPORTs sched,psi: Convert to sched_set_fifo_low() sched,rcutorture: Convert to sched_set_fifo_low() sched,rcuperf: Convert to sched_set_fifo_low() sched,locktorture: Convert to sched_set_fifo() sched,irq: Convert to sched_set_fifo() sched,watchdog: Convert to sched_set_fifo() sched,serial: Convert to sched_set_fifo() sched,powerclamp: Convert to sched_set_fifo() sched,ion: Convert to sched_set_normal() sched,powercap: Convert to sched_set_fifo*() sched,spi: Convert to sched_set_fifo*() sched,mmc: Convert to sched_set_fifo*() sched,ivtv: Convert to sched_set_fifo*() sched,drm/scheduler: Convert to sched_set_fifo*() sched,msm: Convert to sched_set_fifo*() sched,psci: Convert to sched_set_fifo*() sched,drbd: Convert to sched_set_fifo*() ...
| * sched,mmc: Convert to sched_set_fifo*()Peter Zijlstra2020-06-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Because SCHED_FIFO is a broken scheduler model (see previous patches) take away the priority field, the kernel can't possibly make an informed decision. In this case, use fifo_low, because it only cares about being above SCHED_NORMAL. Effectively no change in behaviour. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Ingo Molnar <mingo@kernel.org> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
* | Merge tag 'mmc-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmcLinus Torvalds2020-08-058-34/+63
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull MMC updates from Ulf Hansson: "MMC core: - Add a new host cap bit and a corresponding DT property, to support power cycling of the card by FW at system suspend/resume. - Fix clock rate setting for SDIO in SDR12/SDR25 speed-mode - Fix switch to 1/4-bit mode at system suspend/resume for SD-combo cards - Convert the mmc-pwrseq DT bindings to the json-schema - Always allow the card detect uevent to be consumed by userspace MMC host controllers: - Convert a few DT bindings to the json-schema - mtk-sd: - Add support for command queue through cqhci - Add support for the MT6779 variant - renesas_sdhi_internal_dmac: - Fix dma unmapping in the error path - sdhci_am654: - Add support for the AM65x PG2.0 variant - Extend support for phys/clocks - sdhci-cadence: - Drop incorrect HW tuning for SD mode - sdhci-msm: - Add support for interconnect bandwidth scaling - Enable internal voltage control - Enable low power state for pinctrls - sdhci-of-at91: - Ludovic Desroches handovers maintenance to Eugen Hristev - sdhci-pci-gli: - Improve clock handling for GL975x - sdhci-pci-o2micro: - Add HW tuning for SDR104 mode - Fix support for O2 host controller Seabird1" * tag 'mmc-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (66 commits) mmc: mediatek: make function msdc_cqe_disable() static MAINTAINERS: mmc: sdhci-of-at91: handover maintenance to Eugen Hristev dt-bindings: mmc: mediatek: Add document for mt6779 mmc: mediatek: command queue support mmc: mediatek: refine msdc timeout api mmc: mediatek: add MT6779 MMC driver support mmc: sdhci-pci-o2micro: Add HW tuning for SDR104 mode mmc: sdhci-pci-o2micro: Bug fix for O2 host controller Seabird1 mmc: via-sdmmc: use generic power management memstick: jmb38x_ms: use generic power management mmc: sdhci-cadence: do not use hardware tuning for SD mode mmc: sdhci-pci-gli: Set SDR104's clock to 205MHz and enable SSC for GL975x mmc: cqhci: Fix a print format for the task descriptor mmc: sdhci-of-arasan: fix timings allocation code mmc: sdhci: Fix a potential uninitialized variable dt-bindings: mmc: renesas,sdhi: convert to YAML dt-bindings: mmc: convert arasan sdhci bindings to yaml mmc: sdhci: Fix potential null pointer access while accessing vqmmc mmc: core: Add MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPEND dt-bindings: mmc: Add full-pwr-cycle-in-suspend property ...
| * | mmc: core: Add MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPENDYoshihiro Shimoda2020-07-132-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit 5a36d6bcdf23 ("mmc: core: Add DT-bindings for MMC_CAP2_FULL_PWR_CYCLE") added the "full-pwr-cycle" property which is possible to perform a full power cycle of the card at any time. However, some environment (like r8a77951-salvator-xs) is possible to perform a full power cycle of the card in suspend via firmware (PSCI on arm-trusted-firmware). So, in worst case, since we are not doing a graceful shutdown of the eMMC device (just cut VCCQ while the eMMC is "sleeping") in suspend, it could lead to internal data corruptions. So, add MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPEND to do a graceful shutdown which issues Power Off notification before entering system suspend. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1594123122-13156-3-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: core: Correct misspelling of 'mq' in mmc_init_request()'s docsLee Jones2020-07-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Correcting this misspelling squashes the following W=1 build warning(s): mmc/core/queue.c:212: warning: Function parameter or member 'mq' not described in '__mmc_init_request' mmc/core/queue.c:212: warning: Excess function parameter 'q' description in '__mmc_init_request' Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200701124702.908713-8-lee.jones@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: core: Add missing documetation for 'mmc' and 'ios'Lee Jones2020-07-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remainder of the kerneldoc descriptions look present and correct. Fixes the following W=1 kernel build warnings: drivers/mmc/core/regulator.c:178: warning: Function parameter or member 'mmc' not described in 'mmc_regulator_set_vqmmc' drivers/mmc/core/regulator.c:178: warning: Function parameter or member 'ios' not described in 'mmc_regulator_set_vqmmc' Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200701124702.908713-4-lee.jones@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: core: Provide description for sdio_set_host_pm_flags()'s 'flag' argLee Jones2020-07-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add missing kerneldoc entry for sdio_set_host_pm_flags()'s 'flag' function argument. Fixes the following W=1 kernel build warning: kernel/drivers/mmc/core/sdio_io.c:722: warning: Function parameter or member 'flags' not described in 'sdio_set_host_pm_flags' Cc: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200701124702.908713-3-lee.jones@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: core: Mark fixups as __maybe_unusedLee Jones2020-07-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not all source files which include quirks.h make use of the all of the available fixup information. When this happens the compiler complains that some constant variables are defined by never used. We can fix this by telling the compiler that this intentional by simply marking them as __maybe_unused. Fixes the following W=1 kernel build warnings: In file included from drivers/mmc/core/sdio.c:22: drivers/mmc/core/quirks.h:105:31: warning: ‘mmc_ext_csd_fixups’ defined but not used [-Wunused-const-variable=] 105 | static const struct mmc_fixup mmc_ext_csd_fixups[] = { | ^~~~~~~~~~~~~~~~~~ drivers/mmc/core/quirks.h:17:31: warning: ‘mmc_blk_fixups’ defined but not used [-Wunused-const-variable=] 17 | static const struct mmc_fixup mmc_blk_fixups[] = { | ^~~~~~~~~~~~~~ In file included from drivers/mmc/core/mmc.c:25: drivers/mmc/core/quirks.h:123:31: warning: ‘sdio_fixup_methods’ defined but not used [-Wunused-const-variable=] 123 | static const struct mmc_fixup sdio_fixup_methods[] = { | ^~~~~~~~~~~~~~~~~~ drivers/mmc/core/quirks.h:17:31: warning: ‘mmc_blk_fixups’ defined but not used [-Wunused-const-variable=] 17 | static const struct mmc_fixup mmc_blk_fixups[] = { | ^~~~~~~~~~~~~~ Cc: Andrei Warkentin <andreiw@motorola.com> Cc: Martin Mares <mj@ucw.cz> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200701124702.908713-2-lee.jones@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: core: Set default power mode in mmc_alloc_host()Veerabhadrarao Badiganti2020-07-132-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set the default power mode, MMC_POWER_UNDEFINED, in mmc_alloc_host() rather than in mmc_start_host(). This enables host drivers to make use of the initial state during ->probe(). Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Link: https://lore.kernel.org/r/1592919288-1020-3-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: sdio: fix clock rate setting for SDR12/SDR25 modeHaibo Chen2020-07-131-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In current code logic, when work in SDR12/SDR25 mode, the final clock rate is incorrect, just the legancy 400KHz, because the card->sw_caps.sd3_bus_mode do not has the flag SD_MODE_UHS_SDR12 or SD_MODE_UHS_SDR25. Besides, SDIO_SPEED_SDR12 is actually value 0, and every mode need to config the timing and clock rate, so remove the ‘if’ operator. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Tested-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/1592813959-5914-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: sdio: Fix 1-bit mode for SD-combo cards during suspendYue Hu2020-07-131-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6b5eda369ac3 ("sdio: put active devices into 1-bit mode during suspend") disabled 4-bit mode during system suspend. After this patch, commit 7310ece86ad7 ("mmc: implement SD-combo (IO+mem) support") used new sdio_enable_4bit_bus() instead of sdio_enable_wide() to support SD-combo cards, also for card resume. However, no corresponding support added during suspend. That is not correct. Let's fix it. Signed-off-by: Yue Hu <huyue2@yulong.com> Link: https://lore.kernel.org/r/20200609081431.6376-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: sdio: Enable SDIO 4-bit bus if not support SD_SCR_BUS_WIDTH_4 for SD ↵Yue Hu2020-07-131-14/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | combo card If the card type is SD combo(MMC_TYPE_SD_COMBO) and the memory part does not support wider bus(SD_SCR_BUS_WIDTH_4), nothing will be done except return 0. However, we should check whether IO part support wider bus or not. We should use available IO ability if supported. In addition, there's a duplicated check to MMC_CAP_4_BIT_DATA since sdio_enable_wide() will include that check. And we can also save one call site to sdio_enable_wide() after this change. Signed-off-by: Yue Hu <huyue2@yulong.com> Link: https://lore.kernel.org/r/20200608103009.5000-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: sdio: Return ret if sdio_disable_func() failsYue Hu2020-07-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should return any possible error returned by mmc_io_rw_direct() rather than only -EIO in sdio_disable_func() failure path. Signed-off-by: Yue Hu <huyue2@yulong.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200604100102.13572-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: core: Always allow the card detect uevent to be consumedUlf Hansson2020-07-132-5/+8
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The approach to allow userspace ~5s to consume the uevent, which is triggered when a new card is inserted/initialized, currently requires the mmc host to support system wakeup. This is unnecessary limiting, especially for an mmc host that relies on a GPIO IRQ for card detect. More precisely, the mmc host may not support system wakeup for its corresponding struct device, while the GPIO IRQ still could be configured as a wakeup IRQ via enable_irq_wake(). To support all various cases, let's simply drop the need for the wakeup support. Instead let's always register a wakeup source and activate it for all card detect IRQs by calling __pm_wakeup_event(). Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200529102341.12529-1-ulf.hansson@linaro.org
* | mmc: remove the call to check_disk_changeChristoph Hellwig2020-07-081-3/+0
| | | | | | | | | | | | | | | | The mmc driver doesn't support event notifications, which means that check_disk_change is a no-op. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
* | blk-mq: move failure injection out of blk_mq_complete_requestChristoph Hellwig2020-06-241-4/+4
|/ | | | | | | | | | | | | Move the call to blk_should_fake_timeout out of blk_mq_complete_request and into the drivers, skipping call sites that are obvious error handlers, and remove the now superflous blk_mq_force_complete_rq helper. This ensures we don't keep injecting errors into completions that just terminate the Linux request after the hardware has been reset or the command has been aborted. Reviewed-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
* mmc: core: Export device/vendor ids from Common CIS for SDIO cardsPali Rohár2020-05-293-2/+51
| | | | | | | | | | | | | | | | | | | | | | | Device/vendor ids from Common CIS (Card Information Structure) may be different as device/vendor ids from CIS on particular SDIO function. Kernel currently exports only device/vendor ids from SDIO functions and not "main" device/vendor ids from Common CIS. This patch exports "main" device/vendor ids for SDIO and SD combo cards at top level mmc device in sysfs hierarchy. Userspace can use e.g. udev rules to correctly match whole SDIO card based on Common CIS device/vendor id and not only one particular SDIO function. Having this information in userspace also helps developers to debug whole SDIO card as e.g. kernel mmc quirks use device/vendor ids from Common CIS and not from particular SDIO function. Also it allows to write userspace applications which list all connected SDIO cards based on CIS ids. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Link: https://lore.kernel.org/r/20200527110858.17504-2-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Do not export MMC_NAME= and MODALIAS=mmc:block for SDIO cardsPali Rohár2020-05-291-0/+7
| | | | | | | | | | SDIO non-combo cards are not handled by mmc_block driver and do not have accessible CID register which is used for MMC_NAME= construction. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Link: https://lore.kernel.org/r/20200527110858.17504-1-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdio: Fix macro name for Marvell device with ID 0x9134Pali Rohár2020-05-281-1/+1
| | | | | | | | | | | | | | | | | | Marvell SDIO device ID 0x9134 is used in SDIO Common CIS (Card Information Structure) and not in SDIO wlan function (with ID 1). SDIO Common CIS is accessed by function ID 0. So change this misleading macro name to SDIO_DEVICE_ID_MARVELL_8887_F0 as it does not refer to wlan function. It refers to function 0. Wlan module on this SDIO card is available at function ID 1 and is identified by different SDIO device ID 0x9135. Kernel quirks for SDIO devices are matched against device ID from SDIO Common CIS. Therefore device ID used in quirk is correct, just has misleading name. Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20200522144412.19712-2-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* Merge branch 'fixes' into nextUlf Hansson2020-05-281-1/+1
|\
| * mmc: block: Fix use-after-free issue for rpmbPeng Hao2020-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The data structure member “rpmb->md” was passed to a call of the function “mmc_blk_put” after a call of the function “put_device”. Reorder these function calls to keep the data accesses consistent. Fixes: 1c87f7357849 ("mmc: block: Fix bug when removing RPMB chardev ") Signed-off-by: Peng Hao <richard.peng@oppo.com> Cc: stable@vger.kernel.org [Uffe: Fixed up mangled patch and updated commit message] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* | mmc: core: Enable erase/discard/trim support for all mmc hostsUlf Hansson2020-05-281-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | Step by step, mmc host drivers and the mmc core have been improved in regards to support erase/discard/trim operations. We have now reached a point when it no longer seems reasonable to use an opt-in approach to enable the functionality. Therefore, let's switch to make the operations always supported. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200508112853.23525-1-ulf.hansson@linaro.org Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
* | mmc: core: expose info about enhanced rpmb supportKrishna Konda2020-05-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following eMMC JEDEC JESD84-B51 standard, an enhanced form of rpmb is supported. What this enhanced mode supports is in addition to be able to write one rpmb or two rpmb frames at a time, 32 frames can be written at a time. Expose this information present in ext csd field so that the user space application that wants to make use of this can do so. Signed-off-by: Krishna Konda <kkonda@codeaurora.org> Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Link: https://lore.kernel.org/r/1588341189-4371-1-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* | mmc: sdio: Align the initialization commands in retry path for UHS-IUlf Hansson2020-05-281-27/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | According to the comment in mmc_sdio_reinit_card(), some SDIO cards may require a "[CMD5,5,3,7] init sequence", which isn't always obeyed in mmc_sdio_init_card(). Especially, when we end up retrying the UHS-I specific initialization, there is a missing CMD5. Let's update the code to make the behaviour consistent and let's also take the opportunity to clean up the code a bit, to avoid open coding. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-5-ulf.hansson@linaro.org
* | mmc: sdio: Re-use negotiated OCR mask when re-sending CMD8Ulf Hansson2020-05-281-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | While initializing an SDIO card in mmc_sdio_init_card(), we may need to retry the UHS-I specific initialization, in case the first attempt fails. This leads to resending a CMD8, but also to restart from scratch with the so called OCR mask negotiations. This is unnecessary as we already have a negotiated OCR mask, so let's use that instead. In this way, the behaviour also becomes more consistent with other similar paths. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-4-ulf.hansson@linaro.org
* | mmc: sdio: Fix several potential memory leaks in mmc_sdio_init_card()Ulf Hansson2020-05-281-31/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Over the years, the code in mmc_sdio_init_card() has grown to become quite messy. Unfortunate this has also lead to that several paths are leaking memory in form of an allocated struct mmc_card, which includes additional data, such as initialized struct device for example. Unfortunate, it's a too complex task find each offending commit. Therefore, this change fixes all memory leaks at once. Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-3-ulf.hansson@linaro.org
* | mmc: sdio: Fix potential NULL pointer error in mmc_sdio_init_card()Ulf Hansson2020-05-281-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During some scenarios mmc_sdio_init_card() runs a retry path for the UHS-I specific initialization, which leads to removal of the previously allocated card. A new card is then re-allocated while retrying. However, in one of the corresponding error paths we may end up to remove an already removed card, which likely leads to a NULL pointer exception. So, let's fix this. Fixes: 5fc3d80ef496 ("mmc: sdio: don't use rocr to check if the card could support UHS mode") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-2-ulf.hansson@linaro.org
* | mmc: core: Use DEFINE_DEBUGFS_ATTRIBUTE instead of DEFINE_SIMPLE_ATTRIBUTEZou Wei2020-05-281-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes coccicheck warning: drivers/mmc/core/debugfs.c:222:0-23: WARNING: mmc_clock_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE for debugfs files Fixes: 703aae3d09a4b ("mmc: add a file to debugfs for changing host clock at runtime") Fixes: a04c50aaa916f ("mmc: core: no need to check return value of debugfs_create functions") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Link: https://lore.kernel.org/r/1587633319-19835-1-git-send-email-zou_wei@huawei.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* | mmc: sd: use HIGH_SPEED_BUS_SPEED in mmc_sd_switch_hs()Jisheng Zhang2020-05-281-2/+2
| | | | | | | | | | | | | | | | | | Use the well defined HIGH_SPEED_BUS_SPEED macro in mmc_sd_switch_hs() to make code more readable. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200410145643.630b0731@xhacker.debian Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* | mmc: core: Return 1 from mmc_regulator_set_vqmmc() if switch skippedMarek Vasut2020-05-281-3/+14
|/ | | | | | | | | | | Adjust mmc_regulator_set_vqmmc() to return 1 if the voltage switch was skipped because the regulator voltage was already correct. This allows drivers to detect such condition and possibly skip various voltage switching extras. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20200416163649.336967-2-marex@denx.de Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: block: Fix request completion in the CQE timeout pathAdrian Hunter2020-05-081-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | First, it should be noted that the CQE timeout (60 seconds) is substantial so a CQE request that times out is really stuck, and the race between timeout and completion is extremely unlikely. Nevertheless this patch fixes an issue with it. Commit ad73d6feadbd7b ("mmc: complete requests from ->timeout") preserved the existing functionality, to complete the request. However that had only been necessary because the block layer timeout handler had been marking the request to prevent it from being completed normally. That restriction was removed at the same time, the result being that a request that has gone will have been completed anyway. That is, the completion was unnecessary. At the time, the unnecessary completion was harmless because the block layer would ignore it, although that changed in kernel v5.0. Note for stable, this patch will not apply cleanly without patch "mmc: core: Fix recursive locking issue in CQE recovery path" Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: ad73d6feadbd7b ("mmc: complete requests from ->timeout") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200508062227.23144-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Fix recursive locking issue in CQE recovery pathSarthak Garg2020-05-081-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following stack trace -001|raw_spin_lock_irqsave -002|mmc_blk_cqe_complete_rq -003|__blk_mq_complete_request(inline) -003|blk_mq_complete_request(rq) -004|mmc_cqe_timed_out(inline) -004|mmc_mq_timed_out mmc_mq_timed_out acquires the queue_lock for the first time. The mmc_blk_cqe_complete_rq function also tries to acquire the same queue lock resulting in recursive locking where the task is spinning for the same lock which it has already acquired leading to watchdog bark. Fix this issue with the lock only for the required critical section. Cc: <stable@vger.kernel.org> Fixes: 1e8e55b67030 ("mmc: block: Add CQE support") Suggested-by: Sahitya Tummala <stummala@codeaurora.org> Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1588868135-31783-1-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Check request type before completing the requestVeerabhadrarao Badiganti2020-05-081-1/+2
| | | | | | | | | | | | | | | | | | | | | In the request completion path with CQE, request type is being checked after the request is getting completed. This is resulting in returning the wrong request type and leading to the IO hang issue. ASYNC request type is getting returned for DCMD type requests. Because of this mismatch, mq->cqe_busy flag is never getting cleared and the driver is not invoking blk_mq_hw_run_queue. So requests are not getting dispatched to the LLD from the block layer. All these eventually leading to IO hang issues. So, get the request type before completing the request. Cc: <stable@vger.kernel.org> Fixes: 1e8e55b67030 ("mmc: block: Add CQE support") Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1588775643-18037-2-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: make mmc_interrupt_hpi() staticJason Yan2020-04-201-1/+1
| | | | | | | | | | | | | Fix the following sparse warning: drivers/mmc/core/mmc_ops.c:881:5: warning: symbol 'mmc_interrupt_hpi' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Fixes: 55c2b8b9a383 ("mmc: core: Re-work the code for eMMC sanitize") Link: https://lore.kernel.org/r/20200403034727.11879-1-yanaijie@huawei.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Re-work the code for eMMC sanitizeUlf Hansson2020-03-264-60/+38
| | | | | | | | | | | | | | | | | | | | The error path for sanitize operations that completes with -ETIMEDOUT, is tightly coupled with the internal request handling code of the core. More precisely, mmc_wait_for_req_done() checks for specific sanitize errors. This is not only inefficient as it affects all types of requests, but also hackish. Therefore, let's improve the behaviour by moving the error path out of the mmc core. To do that, retuning needs to be held while running the sanitize operation. Moreover, to avoid exporting unnecessary symbols to the mmc block module, let's move the code into the mmc_ops.c file. While updating the actual code, let's also take the opportunity to clean up some of the mess around it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200316152152.15122-1-ulf.hansson@linaro.org
* mmc: mmc_test: Pass different sg lists for non-blocking requestsVeerabhadrarao Badiganti2020-03-241-12/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Supply a separate sg list for each of the request in non-blocking IO test cases where two requests will be issued at same time. Otherwise, sg memory may get unmapped when a request is done while same memory is being accessed by controller from the other request, and it leads to iommu errors with below call stack: __arm_lpae_unmap+0x2e0/0x478 arm_lpae_unmap+0x54/0x70 arm_smmu_unmap+0x64/0xa4 __iommu_unmap+0xb8/0x1f0 iommu_unmap_fast+0x38/0x48 __iommu_dma_unmap+0x88/0x108 iommu_dma_unmap_sg+0x90/0xa4 sdhci_post_req+0x5c/0x78 mmc_test_start_areq+0x10c/0x120 [mmc_test] mmc_test_area_io_seq+0x150/0x264 [mmc_test] mmc_test_rw_multiple+0x174/0x1c0 [mmc_test] mmc_test_rw_multiple_sg_len+0x44/0x6c [mmc_test] mmc_test_profile_sglen_wr_nonblock_perf+0x6c/0x94 [mmc_test] mtf_test_write+0x238/0x3cc [mmc_test] Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582714668-17247-1-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Fix indentationJérôme Pouiller2020-03-241-7/+8
| | | | | | | | sdio_single_irq_set() was indented with a mix of tabs and spaces. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20200221163147.608677-1-Jerome.Pouiller@silabs.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Fixup support for HW busy detection for HPI commandsUlf Hansson2020-03-241-11/+25
| | | | | | | | | | | | | | | | | | | In case the host specify a max_busy_timeout, we need to validate that the needed timeout for the HPI command conforms to that requirement. If that's not the case, let's convert from a R1B response to a R1 response, as to instruct the host to avoid HW busy detection. Additionally, when R1B is used we must also inform the host about the busy timeout for the command, so let's do that via updating cmd.busy_timeout. Finally, when R1B is used and in case the host supports HW busy detection, there should be no need for doing polling, so then skip that. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-12-ulf.hansson@linaro.org
* mmc: core: Convert to mmc_poll_for_busy() for HPI commandsUlf Hansson2020-03-242-15/+6
| | | | | | | | | | | | | | | | | | | Rather than open coding the polling loop in mmc_interrupt_hpi(), let's convert to use mmc_poll_for_busy(). Note that, moving to mmc_poll_for_busy() for HPI also improves the behaviour according to below. - Adds support for polling via the optional ->card_busy() host ops. - Require R1_READY_FOR_DATA to be set in the CMD13 response before exiting the polling loop. - Adds a throttling mechanism to avoid CPU hogging when polling. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-11-ulf.hansson@linaro.org
* mmc: core: Drop redundant out-parameter to mmc_send_hpi_cmd()Ulf Hansson2020-03-241-4/+2
| | | | | | | | | | The 'u32 *status' is unused by the caller, so let's drop it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-10-ulf.hansson@linaro.org
* mmc: core: Convert to mmc_poll_for_busy() for erase/trim/discardUlf Hansson2020-03-243-40/+33
| | | | | | | | | | | | | | | | | | | | | | | | | Rather than open coding the polling loop in mmc_do_erase(), let's convert to use mmc_poll_for_busy(). To allow a slightly different error parsing during polling, compared to the __mmc_switch() case, a new in-parameter to mmc_poll_for_busy() is needed, but other than that the conversion is straight forward. Besides addressing the open coding issue, moving to mmc_poll_for_busy() for erase/trim/discard improves the behaviour according to below. - Adds support for polling via the optional ->card_busy() host ops. - Returns zero to indicate success when the final polling attempt finds the card non-busy, even if the timeout expired. - Exits the polling loop when state moves to R1_STATE_TRAN, rather than when leaving R1_STATE_PRG. - Decreases the starting range for throttling to 32-64us. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-9-ulf.hansson@linaro.org
* mmc: core: Update CMD13 busy check for CMD6 commandsUlf Hansson2020-03-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Through mmc_poll_for_busy() a CMD13 may be sent to get the status of the (e)MMC card. If the state of the card is R1_STATE_PRG, the card is considered as being busy, which means we continue to poll with CMD13. This seems to be sufficient, but it's also unnecessary fragile, as it means a new command/request could potentially be sent to the card when it's in an unknown state. To try to improve the situation, but also to move towards a more consistent CMD13 polling behaviour in the mmc core, let's deploy the same policy we use for regular I/O write requests. In other words, let's check that card returns to the R1_STATE_TRAN and that the R1_READY_FOR_DATA bit is set in the CMD13 response, before exiting the polling loop. Note that, potentially this changed behaviour could lead to unnecessary waiting for the timeout to expire, if the card for some reason, moves to an unexpected error state. However, as we bail out from the polling loop when R1_SWITCH_ERROR bit is set or when the CMD13 fails, this shouldn't be an issue. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-8-ulf.hansson@linaro.org
* mmc: core: Enable re-use of mmc_blk_in_tran_state()Ulf Hansson2020-03-241-20/+4
| | | | | | | | | | | | | To allow subsequent changes to re-use the code from the static function mmc_blk_in_tran_state(), let's move it to a public header. While at it, let's also rename it to mmc_ready_for_data(), as to try to better describe its purpose. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-7-ulf.hansson@linaro.org
* mmc: core: Split up mmc_poll_for_busy()Ulf Hansson2020-03-241-16/+31
| | | | | | | | | | | | To make the code more readable, move the part that gets the busy status of the card out into a separate function, mmc_busy_status(). Then call it from mmc_poll_for_busy(). Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-6-ulf.hansson@linaro.org
* mmc: core: Drop redundant in-parameter to __mmc_switch()Ulf Hansson2020-03-243-20/+15
| | | | | | | | | | | The use_busy_signal in-parameter is set true by all callers of __mmc_switch(), hence it's redundant so drop it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-5-ulf.hansson@linaro.org
* mmc: core: Extend mmc_switch_status() to rid of __mmc_switch_status()Ulf Hansson2020-03-243-17/+11
| | | | | | | | | | | | To simplify code, let's extend mmc_switch_status() to cope with needs addressed in __mmc_switch_status(). Then move all users to the updated mmc_switch_status() API and drop __mmc_switch_status() altogether. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-4-ulf.hansson@linaro.org
* mmc: core: Drop unused defineUlf Hansson2020-03-241-1/+0
| | | | | | | | | | | The last user of MMC_OPS_TIMEOUT_MS was recently removed, however the define stayed around. Let's remove it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-3-ulf.hansson@linaro.org
* mmc: core: Throttle polling rate for CMD6Ulf Hansson2020-03-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | In mmc_poll_for_busy() we loop continuously, either by sending a CMD13 or by invoking the ->card_busy() host ops, as to detect when the card stops signaling busy. This behaviour is problematic as it may cause CPU hogging, especially when the busy signal time reaches beyond a few ms. Let's fix the issue by adding a throttling mechanism, that inserts a usleep_range() in between the polling attempts. The sleep range starts at 32-64us, but increases for each loop by a factor of 2, up until the range reaches ~32-64ms. In this way, we are able to keep the loop fine-grained enough for short busy signaling times, while also not hogging the CPU for longer times. Note that, this change is inspired by the similar throttling mechanism that we already use for mmc_do_erase(). Reported-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200204085449.32585-2-ulf.hansson@linaro.org
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-22 10:03:48 +0000