kernel/linux.git/drivers/mmc/core/sdio.c, branch v5.16

mmc: core: Use pm_runtime_resume_and_get() to replace open coding

2021-06-14T11:57:41+00:00

use pm_runtime_resume_and_get() to replace pm_runtime_get_sync and pm_runtime_put_noidle. this change is just to simplify the code, no actual functional changes Signed-off-by: Tian Tao Link: https://lore.kernel.org/r/1621513304-27824-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Ulf Hansson

mmc: core: Fix hanging on I/O during system suspend for removable cards

2021-03-30T09:42:03+00:00

The mmc core uses a PM notifier to temporarily during system suspend, turn off the card detection mechanism for removal/insertion of (e)MMC/SD/SDIO cards. Additionally, the notifier may be used to remove an SDIO card entirely, if a corresponding SDIO functional driver don't have the system suspend/resume callbacks assigned. This behaviour has been around for a very long time. However, a recent bug report tells us there are problems with this approach. More precisely, when receiving the PM_SUSPEND_PREPARE notification, we may end up hanging on I/O to be completed, thus also preventing the system from getting suspended. In the end what happens, is that the cancel_delayed_work_sync() in mmc_pm_notify() ends up waiting for mmc_rescan() to complete - and since mmc_rescan() wants to claim the host, it needs to wait for the I/O to be completed first. Typically, this problem is triggered in Android, if there is ongoing I/O while the user decides to suspend, resume and then suspend the system again. This due to that after the resume, an mmc_rescan() work gets punted to the workqueue, which job is to verify that the card remains inserted after the system has resumed. To fix this problem, userspace needs to become frozen to suspend the I/O, prior to turning off the card detection mechanism. Therefore, let's drop the PM notifiers for mmc subsystem altogether and rely on the card detection to be turned off/on as a part of the system_freezable_wq, that we are already using. Moreover, to allow and SDIO card to be removed during system suspend, let's manage this from a ->prepare() callback, assigned at the mmc_host_class level. In this way, we can use the parent device (the mmc_host_class device), to remove the card device that is the child, in the device_prepare() phase. Reported-by: Kiwoong Kim Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210310152900.149380-1-ulf.hansson@linaro.org Reviewed-by: Kiwoong Kim

mmc: core: remove unused host parameter of mmc_sd_get_csd()

2021-02-01T10:54:48+00:00

The host parameter is not used in the body of mmc_sd_get_csd(), so let's remove it. Update related code at the same time. Signed-off-by: Yue Hu Link: https://lore.kernel.org/r/20210118084520.241-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson

mmc: sdio: Export SDIO revision and info strings to userspace

2020-09-07T07:11:29+00:00

For SDIO functions, SDIO cards and SD COMBO cards are exported revision number and info strings from CISTPL_VERS_1 structure. Revision number should indicate compliance of standard and info strings should contain product information in same format as product information for PCMCIA cards. Product information for PCMCIA cards should contain following strings in this order: Manufacturer, Product Name, Lot number, Programming Conditions. Note that not all SDIO cards export all those info strings in that order as described in PCMCIA Metaformat Specification. Signed-off-by: Pali Rohár Link: https://lore.kernel.org/r/20200727133837.19086-5-pali@kernel.org Signed-off-by: Ulf Hansson

mmc: sdio: fix clock rate setting for SDR12/SDR25 mode

2020-07-13T10:18:24+00:00

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 Tested-by: Pali Rohár Link: https://lore.kernel.org/r/1592813959-5914-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson

mmc: sdio: Fix 1-bit mode for SD-combo cards during suspend

2020-07-13T10:18:23+00:00

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 Link: https://lore.kernel.org/r/20200609081431.6376-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson

mmc: sdio: Enable SDIO 4-bit bus if not support SD_SCR_BUS_WIDTH_4 for SD combo card

2020-07-13T10:18:23+00:00

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 Link: https://lore.kernel.org/r/20200608103009.5000-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson

mmc: core: Export device/vendor ids from Common CIS for SDIO cards

2020-05-29T10:38:00+00:00

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 Reviewed-by: Marek Behún Link: https://lore.kernel.org/r/20200527110858.17504-2-pali@kernel.org Signed-off-by: Ulf Hansson

mmc: sdio: Align the initialization commands in retry path for UHS-I

2020-05-28T09:21:03+00:00

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 Link: https://lore.kernel.org/r/20200430091640.455-5-ulf.hansson@linaro.org

mmc: sdio: Re-use negotiated OCR mask when re-sending CMD8

2020-05-28T09:21:03+00:00

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 Link: https://lore.kernel.org/r/20200430091640.455-4-ulf.hansson@linaro.org