linux-stable.git/include/linux/mmc/host.h, branch v5.12.8

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

2021-05-12T06:39:31+00:00

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: Drop redundant member in struct mmc host

2021-02-08T11:53:11+00:00

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:33+00:00

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:47+00:00

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:28+00:00

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:31+00:00

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

mmc: core: Improve documentation of MMC_CAP_HW_RESET

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

MMC_CAP_HW_RESET means that the controller is capable of resetting the eMMC
device via RST_n signal, not a reset of the controller. Two drivers got
this wrong, so let's make it more clear.

Signed-off-by: Wolfram Sang 
Link: https://lore.kernel.org/r/20200821063533.3771-1-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson

mmc: core: Add MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPEND

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

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: Always allow the card detect uevent to be consumed

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

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: host: Drop redundant MMC_CAP_ERASE

2020-05-28T09:22:14+00:00

The MMC_CAP_ERASE bit is no longer used by the mmc core as erase, discard
and trim operations are now always supported. Therefore, drop the bit and
move all mmc hosts away from using it.

Signed-off-by: Ulf Hansson 
Reviewed-by: Rui Miguel Silva 
Link: https://lore.kernel.org/r/20200508112902.23575-1-ulf.hansson@linaro.org
Reviewed-by: Linus Walleij