raspberrypi inclusion
category: feature
bugzilla: 50432

--------------------------------

mmc: Disable CMD23 transfers on all cards

Pending wire-level investigation of these types of transfers
and associated errors on bcm2835-mmc, disable for now. Fallback of
CMD18/CMD25 transfers will be used automatically by the MMC layer.

Reported/Tested-by: Gellert Weisz <gellert@raspberrypi.org>

mmc: bcm2835-mmc: enable DT support for all architectures

Both ARCH_BCM2835 and ARCH_BCM270x are built with OF now.
Enable Device Tree support for all architectures.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>

mmc: bcm2835-mmc: fix probe error handling

Probe error handling is broken in several places.
Simplify error handling by using device managed functions.
Replace pr_{err,info} with dev_{err,info}.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>

bcm2835-mmc: Add locks when accessing sdhost registers

bcm2835-mmc: Add range of debug options for slowing things down

bcm2835-mmc: Add option to disable some delays

bcm2835-mmc: Add option to disable MMC_QUIRK_BLK_NO_CMD23

bcm2835-mmc: Default to disabling MMC_QUIRK_BLK_NO_CMD23

bcm2835-mmc: Adding overclocking option

Allow a different clock speed to be substitued for a requested 50MHz.
This option is exposed using the "overclock_50" DT parameter.
Note that the mmc interface is restricted to EVEN integer divisions of
250MHz, and the highest sensible option is 63 (250/4 = 62.5), the
next being 125 (250/2) which is much too high.

Use at your own risk.

bcm2835-mmc: Round up the overclock, so 62 works for 62.5Mhz

Also only warn once for each overclock setting.

mmc: bcm2835-mmc: Make available on ARCH_BCM2835

Make the bcm2835-mmc driver available for use on ARCH_BCM2835.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>

BCM270x_DT: add bcm2835-mmc entry

Add Device Tree entry for bcm2835-mmc.
In non-DT mode, don't add the device in the board file.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>

bcm2835-mmc: Don't overwrite MMC capabilities from DT

bcm2835-mmc: Don't override bus width capabilities from devicetree

Take out the force setting of the MMC_CAP_4_BIT_DATA host capability
so that the result read from devicetree via mmc_of_parse() is
preserved.

bcm2835-mmc: Only claim one DMA channel

With both MMC controllers enabled there are few DMA channels left. The
bcm2835-mmc driver only uses DMA in one direction at a time, so it
doesn't need to claim two channels.

See: https://github.com/raspberrypi/linux/issues/1327Signed-off-by: NPhil Elwell <phil@raspberrypi.org>

bcm2835-mmc: New timer API

mmc: bcm2835-mmc: Support underclocking

Support underclocking of the SD bus using the max-frequency DT property
(which currently has no DT parameter). The sd_overclock parameter
already provides another way to achieve the same thing which should be
equivalent in end result, but it is a bug not to support max-frequency
as well.

See: https://github.com/raspberrypi/linux/issues/2350Signed-off-by: NPhil Elwell <phil@raspberrypi.org>

mmc/bcm2835: Recover from MMC_SEND_EXT_CSD

If the user issues an "mmc extcsd read", the SD controller receives
what it thinks is a SEND_IF_COND command with an unexpected data block.
The resulting operations leave the FSM stuck in READWAIT, a state which
persists until the MMC framework resets the controller, by which point
the root filesystem is likely to have been unmounted.

A less heavyweight solution is to detect the condition and nudge the
FSM by asserting the (self-clearing) FORCE_DATA_MODE bit.

N.B. This workaround was essentially discovered by accident and without
a full understanding the inner workings of the controller, so it is
fortunate that the "fix" only modifies error paths.

See: https://github.com/raspberrypi/linux/issues/2728Signed-off-by: NPhil Elwell <phil@raspberrypi.org>

bcm2835-mmc: Fix DMA channel leak

The BCM2835 MMC host driver requests a DMA channel on probe but neglects
to release the channel in the probe error path and on driver unbind.

I'm seeing this happen on every boot of the Compute Module 3: On first
driver probe, DMA channel 2 is allocated and then leaked with a "could
not get clk, deferring probe" message. On second driver probe, channel 4
is allocated.

Fix it.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Frank Pavlic <f.pavlic@kunbus.de>

bcm2835-mmc: Fix struct mmc_host leak on probe

The BCM2835 MMC host driver requests the bus address of the host's
register map on probe.  If that fails, the driver leaks the struct
mmc_host allocated earlier.

Fix it.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Frank Pavlic <f.pavlic@kunbus.de>

bcm2835-mmc: Fix duplicate free_irq() on remove

The BCM2835 MMC host driver requests its interrupt as a device-managed
resource, so the interrupt is automatically freed after the driver is
unbound.

However on driver unbind, bcm2835_mmc_remove() frees the interrupt
explicitly to avoid invocation of the interrupt handler after driver
structures have been torn down.

The interrupt is thus freed twice, leading to a WARN splat in
__free_irq().  Fix by not requesting the interrupt as a device-managed
resource.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Frank Pavlic <f.pavlic@kunbus.de>

bcm2835-mmc: Handle mmc_add_host() errors

The BCM2835 MMC host driver calls mmc_add_host() but doesn't check its
return value.  Errors occurring in that function are therefore not
handled.  Fix it.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Frank Pavlic <f.pavlic@kunbus.de>

bcm2835-mmc: Deduplicate reset of driver data on remove

The BCM2835 MMC host driver sets the device's driver data pointer to
NULL on ->remove() even though the driver core subsequently does the
same in __device_release_driver().  Drop the duplicate assignment.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Frank Pavlic <f.pavlic@kunbus.de>

bcm2835_mmc: Remove vestigial threaded IRQ

With SDIO processing now managed by the MMC framework with a
workqueue, the bcm2835_mmc driver no longer needs a threaded
IRQ.
Signed-off-by: NPhil Elwell <phil@raspberrypi.org>

Add missing dma_unmap_sg calls to free relevant swiotlb bounce buffers.
This prevents DMA leaks.
Signed-off-by: NYaroslav Rosomakho <yaroslavros@gmail.com>

Limit max_req_size under arm64 (or any other platform that uses swiotlb) to prevent potential buffer overflow due to bouncing.
Signed-off-by: NYaroslav Rosomakho <yaroslavros@gmail.com>
Signed-off-by: NFang Yafen <yafen@iscas.ac.cn>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

Add documentation for mmc_hw_reset to make sure the intended use case is
clear.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20200918215446.65654-1-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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.orgSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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

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: NUlf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20200508112853.23525-1-ulf.hansson@linaro.orgReviewed-by: NLinus Walleij <linus.walleij@linaro.org>

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

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: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Tested-by: NLudovic Barre <ludovic.barre@st.com>
Reviewed-by: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200204085449.32585-9-ulf.hansson@linaro.org

The busy timeout that is computed for each erase/trim/discard operation,
can become quite long and may thus exceed the host->max_busy_timeout. If
that becomes the case, mmc_do_erase() converts from using an R1B response
to an R1 response, as to prevent the host from doing HW busy detection.

However, it has turned out that some hosts requires an R1B response no
matter what, so let's respect that via checking MMC_CAP_NEED_RSP_BUSY. Note
that, if the R1B gets enforced, the host becomes fully responsible of
managing the needed busy timeout, in one way or the other.
Suggested-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Cc: <stable@vger.kernel.org>
Tested-by: NAnders Roxell <anders.roxell@linaro.org>
Tested-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Tested-by: NFaiz Abbas <faiz_abbas@ti.com>
Tested-By: NPeter Geis <pgwipeout@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently MMC core disregards host->f_max during card initialization
phase. Obey upper boundary for the clock frequency and skip faster
speeds when they are above the limit.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/f471bceaf237d582d746bd289c4c4f3639cb7b45.1577962382.git.mirq-linux@rere.qmqm.plSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

It have turned out that it's not a good idea to unconditionally do a power
cycle and then to re-initialize the SDIO card, as currently done through
mmc_hw_reset() -> mmc_sdio_hw_reset(). This because there may be multiple
SDIO func drivers probed, who also shares the same SDIO card.

To address these scenarios, one may be tempted to use a notification
mechanism, as to allow the core to inform each of the probed func drivers,
about an ongoing HW reset. However, supporting such an operation from the
func driver point of view, may not be entirely trivial.

Therefore, let's use a more simplistic approach to solve the problem, by
instead forcing the card to be removed and re-detected, via scheduling a
rescan-work. In this way, we can rely on existing infrastructure, as the
func driver's ->remove() and ->probe() callbacks, becomes invoked to deal
with the cleanup and the re-initialization.

This solution may be considered as rather heavy, especially if a func
driver doesn't share its card with other func drivers. To address this,
let's keep the current immediate HW reset option as well, but run it only
when there is one func driver probed for the card.

Finally, to allow the caller of mmc_hw_reset(), to understand if the reset
is being asynchronously managed from a scheduled work, it returns 1
(propagated from mmc_sdio_hw_reset()). If the HW reset is executed
successfully and synchronously it returns 0, which maintains the existing
behaviour.
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Upfront in mmc_rescan() we use the host->rescan_entered flag, to allow
scanning only once for non-removable cards. Therefore, it's also not
possible that we can have a corresponding card bus attached (host->bus_ops
is NULL), when we are scanning non-removable cards.

For this reason, let' drop the check for mmc_card_is_removable() as it's
redundant.
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NEnrico Weigelt <info@metux.net>
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Normally when the MMC core sees an "-EILSEQ" error returned by a host
controller then it will trigger a retuning of the card.  This is
generally a good idea.

However, if a command is expected to sometimes cause transfer errors
then these transfer errors shouldn't cause a re-tuning.  This
re-tuning will be a needless waste of time.  One example case where a
transfer is expected to cause errors is when transitioning between
idle (sometimes referred to as "sleep" in Broadcom code) and active
state on certain Broadcom WiFi SDIO cards.  Specifically if the card
was already transitioning between states when the command was sent it
could cause an error on the SDIO bus.

Let's add an API that the SDIO function drivers can call that will
temporarily disable the auto-tuning functionality.  Then we can add a
call to this in the Broadcom WiFi driver and any other driver that
might have similar needs.

NOTE: this makes the assumption that the card is already tuned well
enough that it's OK to disable the auto-retuning during one of these
error-prone situations.  Presumably the driver code performing the
error-prone transfer knows how to recover / retry from errors.  ...and
after we can get back to a state where transfers are no longer
error-prone then we can enable the auto-retuning again.  If we truly
find ourselves in a case where the card needs to be retuned sometimes
to handle one of these error-prone transfers then we can always try a
few transfers first without auto-retuning and then re-try with
auto-retuning if the first few fail.

Without this change on rk3288-veyron-minnie I periodically see this in
the logs of a machine just sitting there idle:
  dwmmc_rockchip ff0d0000.dwmmc: Successfully tuned phase to XYZ

Cc: stable@vger.kernel.org #v4.18+
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NKalle Valo <kvalo@codeaurora.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The original purpose of the code I fix is to replace max_discard with
max_trim if max_trim is less than max_discard. When max_discard is 0
we should replace max_discard with max_trim as well, because
max_discard equals 0 happens only when the max_do_calc_max_discard
process is overflowed, so if mmc_can_trim(card) is true, max_discard
should be replaced by an available max_trim.
However, in the original code, there are two lines of code interfere
the right process.
1) if (max_discard && mmc_can_trim(card))
when max_discard is 0, it skips the process checking if max_discard
needs to be replaced with max_trim.
2) if (max_trim < max_discard)
the condition is false when max_discard is 0. it also skips the process
that replaces max_discard with max_trim, in fact, we should replace the
0-valued max_discard with max_trim.
Signed-off-by: NJiong Wu <Lohengrin1024@gmail.com>
Fixes: b305882f (mmc: core: optimize mmc_calc_max_discard)
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The busy timeout is 250msec per discard command.
Signed-off-by: NAvri Altman <avri.altman@wdc.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

SD spec v5.1 adds discard support. The flows and commands are similar to
mmc, so just set the discard arg in CMD38.

A host which supports DISCARD shall check if the DISCARD_SUPPORT (b313)
is set in the SD_STATUS register.  If the card does not support discard,
the host shall not issue DISCARD command, but ERASE command instead.

Post the DISCARD operation, the card may de-allocate the discarded
blocks partially or completely. So the host mustn't make any assumptions
concerning the content of the discarded region. This is unlike ERASE
command, in which the region is guaranteed to contain either '0's or
'1's, depends on the content of DATA_STAT_AFTER_ERASE (b55) in the scr
register.

One more important difference compared to ERASE is the busy timeout
which we will address on the next patch.
Signed-off-by: NAvri Altman <avri.altman@wdc.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In case of CQHCI, mrq->cmd may be NULL for data requests (non DCMD).
In such case mmc_should_fail_request is directly dereferencing
mrq->cmd while cmd is NULL.
Fix this by checking for mrq->cmd pointer.

Fixes: 72a5af55 ("mmc: core: Add support for handling CQE requests")
Signed-off-by: NRitesh Harjani <riteshh@codeaurora.org>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The only user of mmc_align_data_size() is sdio_align_size(), which is
called from SDIO func drivers to let them distinguish, how to optimally
allocate data buffers.

Let's move mmc_align_data_size() close to the SDIO code as to make it
static, rename it to _sdio_align_size() and simplify its definition, all
with the purpose of clarifying that this is SDIO specific.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NAvri Altman <avri.altman@wdc.com>

MMC OF parsing functions, which parses various host DT properties, should
stay close to each other. Therefore, let's move mmc_of_parse_voltage()
close to mmc_of_parse() into host.c.

Additionally, there is no reason to build the code only when CONFIG_OF is
set, as there should be stub functions for the OF helpers that is being
used, so let's drop this condition as well.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The mmc regulator helper functions, are placed in the extensive core.c
file.  In a step towards trying to create a better structure of files,
avoiding too many lines of code per file, let's move these helpers to a new
file, regulator.c.

Moreover, this within this context it makes sense to also drop the export
of mmc_vddrange_to_ocrmask(), but instead let's make it internal to the mmc
core.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In MMC, the discard arg is a read-only ext_csd parameter - set it once
on card init. To be consistent, do that for SD as well even though its
discard arg is always 0x0.
Signed-off-by: NAvri Altman <avri.altman@wdc.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

To allow mmc host drivers to inform the mmc core about rather using
pm_runtime_put_sync_suspend() instead of pm_runtime_put_autosuspend(),
let's introduce MMC_CAP_SYNC_RUNTIME_PM.

This is especially useful for those mmc host drivers that don't benefit
from using the runtime PM autosuspend feature. Typically this is those that
relies on parent devices to power the card via runtime PM, like some USB
host drivers for example.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: NOleksandr Natalenko <oleksandr@natalenko.name>

The only user was converted to fill a sbc command which is the proper
way to do it because of AutoCMD23 feature of some hosts.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: NClément Péron <peron.clem@gmail.com>
Reviewed-by: NAvri Altman <avri.altman@wdc.com>
Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The last user of mmc_power_save|restore_host() APIs is gone, hence let's
drop them. Drop also the corresponding bus_ops callback,
->power_save|restore() as those becomes redundant.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Eyal Reizer <eyalreizer@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

R1_STATUS(x) now is only used by ioctl_rpmb_card_status_poll(),
which checks all bits as possible. But according to the spec,
bit 17 and bit 18 should be ignored, as well bit 14 which is
reserved(must be set to 0) quoting from the spec and these rule
apply to all places checking the device status. So change
its checking from 0xFFFFE000 to 0xFFF9A000.

As a bonus, we reuse it for mmc_do_erase() as well as
mmc_switch_status_error().
(1) Currently mmc_switch_status_error() doesn't check bit 25, but
it means device is locked but not unlocked by CMD42 prior to any
operations which need check busy, which is also not allowed.
(2) mmc_do_erase() also forgot to to check bit 15, WP_ERASE_SKIP.
The spec says "Only partial address space was erased due to existing
write protected blocks.", which obviously means we should fail this I/O.
Otherwise, the partial erased data stored in nonvalatile flash violates
the data integrity from the view of I/O owner, which probably confuse
it when further used.

So reusing R1_STATUS for them not only improve the readability but also
slove real problems.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This drastically reduces the rate at which the MMC_SEND_STATUS cmd polls
for completion of the MMC Erase operation.  The patch does this by adding
a backoff sleep that starts by sleeping for short intervals (128-256us),
and ramps up to sleeping for 32-64ms.

Even on very quickly completing erase operations, the loop iterates a few
times, so not too much extra latency is added to these commands.

For long running discard operarations, like a full-device secure discard,
this change drops the interrupt rates on my single-core NXP I.MX6UL from
45000/s to about 20/s, and greatly improves system responsiveness.
Signed-off-by: NMartin Hicks <mort@bork.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The hard-coded 10ms delay in mmc_power_up came from
commit 79bccc5a ("mmc: increase power up delay"), which said "The TI
controller on Toshiba Tecra M5 needs more time to power up or the cards
will init incorrectly or not at all." But it's too engineering solution
for a special board but force all platforms to wait for that long time,
especially painful for mmc_power_up for eMMC when booting.

However, it's added since 2009, and we can't tell if other platforms
benefit from it. But in practise, the modern hardware are most likely to
have a stable power supply with 1ms after setting it for no matter PMIC
or discrete power. And more importnatly, most regulators implement the
callback of ->set_voltage_time_sel() for regulator core to wait for
specific period of time for the power supply to be stable, which means
once regulator_set_voltage_* return, the power should reach the the
minimum voltage that works for initialization. Of course, if there
are some other ways for host to power the card, we should allow them
to argue a suitable delay as well.

With this patch, we could assign the delay from firmware, or we could
assigne it via ->set_ios() callback from host drivers.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

MMC_CORE_TIMEOUT_MS isn't being used no more, let's drop it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Move the corresponding code for setting the initial signal voltage, from
mmc_power_up() into a new function, mmc_set_initial_signal_voltage().

Make the function internally available to the mmc core, as to allow the
following changes to make use of it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

It's rather common that a firmware is loaded into an SDIO func device
memory, by the corresponding SDIO func driver during ->probe() time.

However, to actually start running the new firmware, sometimes a soft reset
(no power cycle) and a re-initialization of the card is needed. This is for
example the case with the Espressif ESP8089 WiFi chips, when connected to
an SDIO interface.

To cope with this scenario, let's add a new exported function,
mmc_sw_reset(), which may be called when a soft reset and re-initialization
of the card are needed.

The mmc_sw_reset() is implemented on top of a new bus ops callback, similar
to how the mmc_hw_reset() has been implemented.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

The bus ops ->reset() executes a full HW reset of the card, as the calling
function mmc_hw_reset() also indicates by its name. Let's convert to follow
the similar names, for both the bus ops callback and for the corresponding
bus ops functions, as to clarify the purpose of code.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

Commit 03dbaa04 ("mmc: slot-gpio: Add support to enable irq wake on
cd_irq") enabled wakeup at initialization. However drivers may wish to
enable and disable based on different criteria. Add a helper function
mmc_gpio_set_cd_wake() to make it easy for drivers to do that.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

If the max_discard value is zero, the conditional branch that checks the
trim capabilities will never update this value with max_trim.

Change the condition statement to also check the max_discard value in order
to avoid an unnecessary call to mmc_do_calc_max_discard.
Signed-off-by: NSergio Valverde <vlvrdv@gmail.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chip.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The Weibu F3C MiniPC has an onboard AP6255 module, presenting
two SDIO functions on a single MMC host (Bluetooth/btsdio and
WiFi/brcmfmac), and the mmc layer correctly detects this as
non-removable.

After suspend/resume, the wifi and bluetooth interfaces disappear
and do not get probed again.

The conditions here are:

 1. During suspend, we reach mmc_pm_notify()

 2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
    suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
    -ENOSYS because btsdio_driver does not have a suspend method.

 3. mmc_pm_notify() proceeds to remove the card

 4. Upon resume, mmc_rescan() does nothing with this host, because of
    the rescan_entered check which aims to only scan a non-removable
    device a single time (i.e. during boot).

Fix the loss of functionality by detecting that we are unable to
suspend a non-removable host, so avoid the forced removal in that
case. The comment above this function already indicates that this
code was only intended for removable devices.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Remove code no longer needed after the switch to blk-mq.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Remove config option MMC_MQ_DEFAULT and parameter mmc_use_blk_mq, so that
blk-mq must be used always.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_test now uses mmc_start_request() to test sending commands during
"ongoing" asynchronous transfers, i.e. tests:
	Commands during non-blocking read - use Set Block Count (CMD23)
	Commands during non-blocking write - use Set Block Count (CMD23)

mmc_start_request() was not initializing cmd_completion, but cmd_completion
is used by "ongoing" transfers, so move initialization of cmd_completion
into making mmc_start_request().

Fixes: cb39f61e ("mmc: core: Export a few functions needed for blkmq support")
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Until mmc has blk-mq support fully implemented and tested, add a parameter
use_blk_mq, set to true if config option MMC_MQ_DEFAULT is selected, which
it is by default.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>

Make mmc_pre_req() and mmc_post_req() available to the card drivers. Later
patches will make use of this.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>

Especially, make clear what the return value means.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>