user/sven/linux.git/include/linux/mmc, branch v5.13.13

mmc: core: Convert mmc_of_parse_voltage() to use device property API

2021-04-23T07:29:49Z

mmc_of_parse() for a few years has been using device property API. Convert mmc_of_parse_voltage() as well. At the same time switch users to new API. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210419112459.25241-2-andriy.shevchenko@linux.intel.com Signed-off-by: Ulf Hansson

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

2021-03-30T09:42:03Z

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: sdio: fix a typo in the comment of SDIO_SD_REV_3_00

2021-03-30T09:42:03Z

I believe "Spev" is typo, should be "Spec". Signed-off-by: Jisheng Zhang Link: https://lore.kernel.org/r/20210311174157.561dada9@xhacker.debian Signed-off-by: Ulf Hansson

mmc: core: Drop reference counting of the bus_ops

2021-03-30T09:41:58Z

When the mmc_rescan work is enabled for execution (host->rescan_disable), it's the only instance per mmc host that is allowed to set/clear the host->bus_ops pointer. Besides the mmc_rescan work, there are a couple of scenarios when the host->bus_ops pointer may be accessed. Typically, those can be described as as below: *) Upper mmc driver layers (like the mmc block device driver or an SDIO functional driver) needs to execute a host->bus_ops callback. This can be considered as safe without having to use some special locking mechanism, because they operate on top of the struct mmc_card. As long as there is a card to operate upon, the mmc core guarantees that there is a host->bus_ops assigned as well. Note that, upper layer mmc drivers are of course responsible to clean up from themselves from their ->remove() callbacks, otherwise things would fall apart anyways. **) Via the mmc host instance, we may need to force a removal of an inserted mmc card. This happens when a mmc host driver gets unbind, for example. In this case, we protect the host->bus_ops pointer from concurrent accesses, by disabling the mmc_rescan work upfront (host->rescan_disable). See mmc_stop_host() for example. This said, it seems like the reference counting of the host->bus_ops pointer at some point have become superfluous. As this is an old mechanism of the mmc core, it a bit difficult to digest the history of when that could have happened. However, let's drop the reference counting to avoid unnecessary code-paths and lockings. Cc: Pierre Ossman Cc: Russell King Signed-off-by: Ulf Hansson Reviewed-by: Adrian Hunter Link: https://lore.kernel.org/r/20210212131610.236843-1-ulf.hansson@linaro.org

mmc: core: Drop redundant bouncesz from struct mmc_card

2021-02-08T11:53:34Z

The commit de3ee99b097d ("mmc: Delete bounce buffer handling") removed the bounce buffer handling from the mmc core, but forgot to remove the bouncesz member from the struct mmc_card, let's fix it. Signed-off-by: Ulf Hansson Link: https://lore.kernel.org/r/20210202101626.64503-1-ulf.hansson@linaro.org

mmc: core: Drop redundant member in struct mmc host

2021-02-08T11:53:11Z

The Kconfig option to use the blk-mq support was removed in commit 1bec43a3b181 ("mmc: core: Remove option not to use blk-mq"), but forgot to remove the use_blk_mq member in the struct mmc_host, let's fix it. Signed-off-by: Ulf Hansson Link: https://lore.kernel.org/r/20210202101924.69970-1-ulf.hansson@linaro.org

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: Initial support for SD express card/host

2020-11-16T10:59:28Z

In the SD specification v7.10 the SD express card has been added. This new type of removable SD card, can be managed via a PCIe/NVMe based interface, while also allowing backwards compatibility towards the legacy SD interface. To keep the backwards compatibility, it's required to start the initialization through the legacy SD interface. If it turns out that the mmc host and the SD card, both supports the PCIe/NVMe interface, then a switch should be allowed. Therefore, let's introduce some basic support for this type of SD cards to the mmc core. The mmc host, should set MMC_CAP2_SD_EXP if it supports this interface and MMC_CAP2_SD_EXP_1_2V, if also 1.2V is supported, as to inform the core about it. To deal with the switch to the PCIe/NVMe interface, the mmc host is required to implement a new host ops, ->init_sd_express(). Based on the initial communication between the host and the card, host->ios.timing is set to either MMC_TIMING_SD_EXP or MMC_TIMING_SD_EXP_1_2V, depending on if 1.2V is supported or not. In this way, the mmc host can check these values in its ->init_sd_express() ops, to know how to proceed with the handover. Note that, to manage card insert/removal, the mmc core sticks with using the ->get_cd() callback, which means it's the host's responsibility to make sure it provides valid data, even if the card may be managed by PCIe/NVMe at the moment. As long as the card seems to be present, the mmc core keeps the card powered on. Cc: Greg Kroah-Hartman Cc: Arnd Bergmann Cc: Christoph Hellwig Cc: Rui Feng Signed-off-by: Ulf Hansson Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/1603936636-3126-1-git-send-email-rui_feng@realsil.com.cn

mmc: core: add a 'doing_init_tune' flag and a 'mmc_doing_tune' helper

2020-09-07T07:16:31Z

Our driver needs to know when tuning is in progress. 'doing_retune' only covers re-tuning, not the initial tuning. Add another flag to detect the initial tuning state and add a helper which tells us if any kind of tuning is going on. Only implemented for MMC currently because that's where we need it. SD can be added later if it becomes necessary. Signed-off-by: Wolfram Sang Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20200901150250.26236-3-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson