kernel.git/drivers/mmc/core/host.c, branch linux-5.12.y

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

2021-05-12T06:39:31Z

commit 17a17bf50612e6048a9975450cf1bd30f93815b5 upstream. 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 Signed-off-by: Greg Kroah-Hartman

mmc: core: Add basic support for inline encryption

2021-02-01T11:02:33Z

In preparation for adding CQHCI crypto engine (inline encryption) support, add the code required to make mmc_core and mmc_block aware of inline encryption. Specifically: - Add a capability flag MMC_CAP2_CRYPTO to struct mmc_host. Drivers will set this if the host and driver support inline encryption. - Embed a blk_keyslot_manager in struct mmc_host. Drivers will initialize this (as a device-managed resource) if the host and driver support inline encryption. mmc_block registers this keyslot manager with the request_queue of any MMC card attached to the host. - Make mmc_block copy the crypto keyslot and crypto data unit number from struct request to struct mmc_request, so that drivers will have access to them. - If the MMC host is reset, reprogram all the keyslots to ensure that the software state stays in sync with the hardware state. Co-developed-by: Satya Tangirala Signed-off-by: Satya Tangirala Acked-by: Adrian Hunter Reviewed-by: Satya Tangirala Reviewed-and-tested-by: Peng Zhou Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20210126001456.382989-2-ebiggers@kernel.org Signed-off-by: Ulf Hansson

mmc: core: Add helper for parsing clock phase properties

2021-02-01T10:54:47Z

Drivers for MMC hosts that accept phase corrections can take advantage of the helper by embedding an instance of struct mmc_clk_phase_map in their private data and invoking mmc_of_parse_clk_phase() to extract phase parameters. It is the responsibility of the host driver to translate and apply the extracted values to hardware as required. Signed-off-by: Andrew Jeffery Link: https://lore.kernel.org/r/20210114031433.2388532-2-andrew@aj.id.au Signed-off-by: Ulf Hansson

mmc: core: Allow setting slot index via device tree alias

2020-09-07T07:11:32Z

As with GPIO, UART and others, allow specifying the device index via the aliases node in the device tree. On embedded devices, there is often a combination of removable (e.g. SD card) and non-removable MMC devices (e.g. eMMC). Therefore the index might change depending on * host of removable device * removable card present or not This makes it difficult to hardcode the root device, if it is on the non-removable device. E.g. if SD card is present eMMC will be mmcblk1, if SD card is not present at boot, eMMC will be mmcblk0. Alternative solutions like PARTUUIDs do not cover the case where multiple mmcblk devices contain the same image. This is a common issue on devices that can boot both from eMMC (for regular boot) and SD cards (as a temporary boot medium for development). When a firmware image is installed to eMMC after a test boot via SD card, there will be no reliable way to refer to a specific device using (PART)UUIDs oder LABELs. The demand for this feature has led to multiple attempts to implement it, dating back at least to 2012 (see https://www.spinics.net/lists/linux-mmc/msg26586.html for a previous discussion from 2014). All indices defined in the aliases node will be reserved for use by the respective MMC device, moving the indices of devices that don't have an alias up into the non-reserved range. If the aliases node is not found, the driver will act as before. This is a rebased and cleaned up version of https://www.spinics.net/lists/linux-mmc/msg26588.html . Based-on-patch-by: Sascha Hauer Link: https://lkml.org/lkml/2020/8/5/194 Signed-off-by: Matthias Schiffer Link: https://lore.kernel.org/r/20200901085004.2512-2-matthias.schiffer@ew.tq-group.com Signed-off-by: Ulf Hansson

treewide: Use fallthrough pseudo-keyword

2020-08-23T22:36:59Z

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

mmc: core: Add MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPEND

2020-07-13T10:18:26Z

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 Link: https://lore.kernel.org/r/1594123122-13156-3-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Ulf Hansson

mmc: core: Set default power mode in mmc_alloc_host()

2020-07-13T10:18:24Z

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 Link: https://lore.kernel.org/r/1592919288-1020-3-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson

mmc: core: Always allow the card detect uevent to be consumed

2020-07-13T10:18:22Z

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

mmc: core: Remove mmc_gpiod_request_*(invert_gpio)

2019-12-18T12:37:07Z

Now that invert_gpio arguments are unused, let's remove them. Signed-off-by: Michał Mirosław Link: https://lore.kernel.org/r/64d766d1f8af2e22bce32f4ffa453f7234207ad6.1576031637.git.mirq-linux@rere.qmqm.pl Signed-off-by: Ulf Hansson

mmc: core: Rework cd-gpio handling

2019-12-18T12:36:53Z

There are a few places around the code that invert inverted and possibly inverted CD line. That's really confusing. Squash them all into one place in mmc_gpiod_request_cd(). MMC_CAP2_CD_ACTIVE_HIGH is used analogously to WP line: in GPIO mode it is used only at probe time to switch polarity, for native mode it is left as is. Signed-off-by: Michał Mirosław Link: https://lore.kernel.org/r/db189b715596d63caf8c6a088bddc71dd69a879b.1576031637.git.mirq-linux@rere.qmqm.pl Signed-off-by: Ulf Hansson