When use one SDIO wifi which enable the runtime PM feature on i.MX6SX,
we meet system hang. This hang happened during the usdhc runtime resume,
in sdhci_init(), when call the sdhci_set_default_irqs. One interrupt
(SDHCI_INT_CARD_INT) triggered just after the host->ier update and before
the write of register SDHCI_SIGNAL_ENABLE. So in sdhci_irq, it will skip
the call of sdio_signal_irq() because current host->ier do not set the
SDHCI_INT_CARD_INT. So this SDIO wifi interrupt always keep triggered,
let the system stuck in irq handle, can't response any other thread.

This patch add spin lock for the sdhci_set_default_irqs to fix this issue.
Signed-off-by: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1586941255-9237-1-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Implement the request_atomic() API for nonremovable cards, that means
we can submit next request in the irq hard handler context to reduce
latency.

Moreover factor out the AUTO CMD23 checking into a separate function
to reduce duplicate code.
Signed-off-by: NBaolin Wang <baolin.wang7@gmail.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/60142fe6c6c1dbba2696e775564ae2166786f0bc.1586744073.git.baolin.wang7@gmail.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Implement the request_atomic() ops for the sdhci driver to process
one request in the atomic context if the card is nonremovable.

Moreover, we should return BUSY flag if controller has not released
the inhibit bits to allow HSQ trying to send request again in non-atomic
context.
Suggested-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NBaolin Wang <baolin.wang7@gmail.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/9ed34afa9fb42e0c234065cac5401d7826942b55.1586744073.git.baolin.wang7@gmail.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The SD host controller can process one request in the atomic context if
the card is nonremovable, which means we can submit next request in the
irq hard handler when using the MMC host software queue to reduce the
latency. Thus this patch adds a new API request_atomic() for the host
controller, as well as adding support for host software queue to submit
a request by the new request_atomic() API.

Moreover there is an unusual case that the card is busy when trying to
send a command, and we can not polling the card status in interrupt
context by using request_atomic() to dispatch requests. Thus we should
queue a work to try again in the non-atomic context in case the host
releases the busy signal later.
Suggested-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NBaolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/a344e27e506cb2329073cbd5cf65e15cc3cbeba9.1586744073.git.baolin.wang7@gmail.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Spending time under spinlock increases IRQ latencies and also
response times because preemption is disabled.

sdhci_send_command() waits up to 10 ms under spinlock for inhibit bits
to clear. In general inhibit bits will not be set, but there may be
corner cases, especially in the face of errors, where waiting helps.
There might also be dysfunctional hardware that needs the waiting. So
retain the legacy behaviour but do not wait for inhibit bits while under
spinlock. Instead adjust the logic to enable waiting while not under
spinlock. That is mostly straight forward, but in the interrupt handler
it requires deferring an "inhibited" command to the IRQ thread where
sleeping is allowed.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200412090349.1607-6-adrian.hunter@intel.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In preparation for further changes, tidy sdhci_request() a bit.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200412090349.1607-5-adrian.hunter@intel.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

sdhci_finish_data() is defined before it is referenced, so forward
declaration is not necessary.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200412090349.1607-4-adrian.hunter@intel.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

sdhci_send_command() has not been used outside of sdhci.c for many
years. Stop exporting it.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200412090349.1607-3-adrian.hunter@intel.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add 2 helper functions to make the use of the auto-CMD23 flag more
readable.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200412090349.1607-2-adrian.hunter@intel.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use the well defined HIGH_SPEED_BUS_SPEED macro in mmc_sd_switch_hs()
to make code more readable.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200410145643.630b0731@xhacker.debianSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Instead of reimplementing the logic in mmc_regulator_set_vqmmc(), use the
mmc code function directly.

This also allows us to fix a related issue on STM32MP1, when a voltage
switch of 1.8V is done for the eMMC, but the current level is already set
to 1.8V. More precisely, in this scenario the call to the
->post_sig_volt_switch() hangs, indefinitely waiting for the voltage switch
to complete. Fix this problem by checking if mmc_regulator_set_vqmmc()
returned 1 and then skip invoking the callback.
Signed-off-by: NMarek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20200416163649.336967-3-marex@denx.de
[Ulf: Updated the commit message]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Adjust mmc_regulator_set_vqmmc() to return 1 if the voltage switch was
skipped because the regulator voltage was already correct. This allows
drivers to detect such condition and possibly skip various voltage
switching extras.
Signed-off-by: NMarek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20200416163649.336967-2-marex@denx.deSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Patch all drivers which use mmc_regulator_set_vqmmc() and prepare them for
the fact that mmc_regulator_set_vqmmc() can return a value > 0, which would
happen if the signal voltage switch did NOT happen, because the voltage was
already set correctly.
Signed-off-by: NMarek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20200416163649.336967-1-marex@denx.de
[Ulf: Re-worked/simplified the code a bit]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Clang warns:

drivers/mmc/host/sdhci-of-arasan.c:784:9: warning: variable 'ret' is
uninitialized when used here [-Wuninitialized]
        return ret;
               ^~~
drivers/mmc/host/sdhci-of-arasan.c:738:9: note: initialize the variable
'ret' to silence this warning
        int ret;
               ^
                = 0
drivers/mmc/host/sdhci-of-arasan.c:860:9: warning: variable 'ret' is
uninitialized when used here [-Wuninitialized]
        return ret;
               ^~~
drivers/mmc/host/sdhci-of-arasan.c:810:9: note: initialize the variable
'ret' to silence this warning
        int ret;
               ^
                = 0
2 warnings generated.

This looks like a copy paste error. Neither function has handling that
needs ret so just remove it and return 0 directly.

Link: https://github.com/ClangBuiltLinux/linux/issues/996Reported-by: Nkernelci.org bot <bot@kernelci.org>
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20200416182402.16858-1-natechancellor@gmail.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

No need to call platform_get_resource twice when we still have the
pointer from before. Also, use '%pa' for a resource_size_t pointer.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Link: https://lore.kernel.org/r/20200408142252.21958-1-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>

When tuning HS400, if all TAPS are good, we can utilize the SMPCMP
register to select the optimal TAP. For that, we populate a second
bitmap with SMPCMP results and query it in case the regular bitmap is
full (= all good).
Signed-off-by: NMasaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
Signed-off-by: NTakeshi Saito <takeshi.saito.xv@renesas.com>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20200408094638.10375-4-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The comment and the define about how TAPs are selected were confusing to
me because the good TAP was only valid if it was bigger than a *_MAX_*
value. Rename the define and adapt the comment to what really happens.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20200408094638.10375-3-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

To select the best TAP, we need to find the longest stream of set bits
in a bit field. There is now a helper function for bitmaps which
iterates over all region of set bits. Using it makes the code much more
concise and easier to understand. Double so, because we need to handle
two bitmaps in the near future. Remove a superfluous comment while here.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20200408094638.10375-2-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use FIELD_GET and FIELD_PREP to get access to the register fields. Delete
the shift macros and use GENMASK() for the touched macros.

Note that, this has the side-effect of changing the constants to 64-bit on
64-bit platforms.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200408072105.422-2-yamada.masahiro@socionext.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In the SDHCI specification, the Capabilities Register (Offset 0x40h)
is the 64-bit width register, but in Linux, it is represented as two
registers, SDHCI_CAPABILITIES and SDHCI_CAPABILITIES_1 so that drivers
can use 32-bit register accessors.

The upper 32-bit field is associated with SDHCI_CAPABILITIES_1.

Move the definition of SDHCI_CAPABILITIES_1 to the correct place.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200408072105.422-1-yamada.masahiro@socionext.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Modify code to fix the warnings reported by kernel-doc for better
documentation.
Signed-off-by: NManish Narani <manish.narani@xilinx.com>
Link: https://lore.kernel.org/r/1586195015-128992-7-git-send-email-manish.narani@xilinx.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The SDHCI clock operations are platform specific. So it better to define
them separately for particular platform. This will prevent multiple
if..else conditions and will make it easy for user to add their own
clock operations handlers.
Signed-off-by: NManish Narani <manish.narani@xilinx.com>
Link: https://lore.kernel.org/r/1586195015-128992-6-git-send-email-manish.narani@xilinx.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Existing driver code has the platform specific structures scattered
throughout the driver code. Rearrange the platform specific data
structures for more modularity and readability. This will help in adding
new static functions with more ease.
Signed-off-by: NManish Narani <manish.narani@xilinx.com>
Link: https://lore.kernel.org/r/1586195015-128992-5-git-send-email-manish.narani@xilinx.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

There is 'struct sdhci_arasan_data' but also
'struct sdhci_arasan_of_data sdhci_arasan_data'. Rename the latter to
avoid confusion with the name of the struct.
Reported-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NManish Narani <manish.narani@xilinx.com>
Link: https://lore.kernel.org/r/1586195015-128992-4-git-send-email-manish.narani@xilinx.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add support to set tap delays for Xilinx Versal SD controller. The tap
delay registers have moved to SD controller space in Versal. Make the
changes accordingly.
Signed-off-by: NManish Narani <manish.narani@xilinx.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1586195015-128992-3-git-send-email-manish.narani@xilinx.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20200409125422.21842-1-ulf.hansson@linaro.org

The in-parameter struct mmc_data *data is never NULL, because the caller
always provides a valid pointer. Hence drop the corresponding redundant
code.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200407143903.22477-1-ulf.hansson@linaro.org

The in-parameter "wait" is always set to 0 by the caller, hence just drop
it and its corresponding code.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NManuel Lauss <manuel.lauss@gmail.com>
Link: https://lore.kernel.org/r/20200406114337.8802-1-ulf.hansson@linaro.org

The MMC_CAP_ERASE and MMC_CAP_CMD23 flags are already being set in the
common sdhci_setup_host(). This makes it redundant to set them for
sdhci-sprd, so let's drop them.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NBaolin Wang <baolin.wang7@gmail.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200406113724.8504-1-ulf.hansson@linaro.org

Instead of explicitly checking for SDIO specific requests and then
returning an error code, let's set MMC_CAP2_NO_SDIO to tell the mmc core to
prevent them altogether.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20200401145531.23247-1-ulf.hansson@linaro.org

The AMD eMMC 5.0 controller does not support 64 bit DMA.

Fixes: 34597a3f ("mmc: sdhci-acpi: Add support for ACPI HID of AMD Controller with HS400")
Signed-off-by: NRaul E Rangel <rrangel@chromium.org>
Link: https://marc.info/?l=linux-mmc&m=158879884514552&w=2Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200508165344.1.Id5bb8b1ae7ea576f26f9d91c761df7ccffbf58c5@changeidSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

First, it should be noted that the CQE timeout (60 seconds) is substantial
so a CQE request that times out is really stuck, and the race between
timeout and completion is extremely unlikely. Nevertheless this patch
fixes an issue with it.

Commit ad73d6fe ("mmc: complete requests from ->timeout")
preserved the existing functionality, to complete the request.
However that had only been necessary because the block layer
timeout handler had been marking the request to prevent it from being
completed normally. That restriction was removed at the same time, the
result being that a request that has gone will have been completed anyway.
That is, the completion was unnecessary.

At the time, the unnecessary completion was harmless because the block
layer would ignore it, although that changed in kernel v5.0.

Note for stable, this patch will not apply cleanly without patch "mmc:
core: Fix recursive locking issue in CQE recovery path"
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Fixes: ad73d6fe ("mmc: complete requests from ->timeout")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200508062227.23144-1-adrian.hunter@intel.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Consider the following stack trace

-001|raw_spin_lock_irqsave
-002|mmc_blk_cqe_complete_rq
-003|__blk_mq_complete_request(inline)
-003|blk_mq_complete_request(rq)
-004|mmc_cqe_timed_out(inline)
-004|mmc_mq_timed_out

mmc_mq_timed_out acquires the queue_lock for the first
time. The mmc_blk_cqe_complete_rq function also tries to acquire
the same queue lock resulting in recursive locking where the task
is spinning for the same lock which it has already acquired leading
to watchdog bark.

Fix this issue with the lock only for the required critical section.

Cc: <stable@vger.kernel.org>
Fixes: 1e8e55b6 ("mmc: block: Add CQE support")
Suggested-by: NSahitya Tummala <stummala@codeaurora.org>
Signed-off-by: NSarthak Garg <sartgarg@codeaurora.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1588868135-31783-1-git-send-email-vbadigan@codeaurora.orgSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In the request completion path with CQE, request type is being checked
after the request is getting completed. This is resulting in returning
the wrong request type and leading to the IO hang issue.

ASYNC request type is getting returned for DCMD type requests.
Because of this mismatch, mq->cqe_busy flag is never getting cleared
and the driver is not invoking blk_mq_hw_run_queue. So requests are not
getting dispatched to the LLD from the block layer.

All these eventually leading to IO hang issues.
So, get the request type before completing the request.

Cc: <stable@vger.kernel.org>
Fixes: 1e8e55b6 ("mmc: block: Add CQE support")
Signed-off-by: NVeerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1588775643-18037-2-git-send-email-vbadigan@codeaurora.orgSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Need to clear some bits in a vendor-defined register after reboot from
Windows 10.

Fixes: e51df6ce ("mmc: host: sdhci-pci: Add Genesys Logic GL975x support")
Reported-by: NGrzegorz Kowal <custos.mentis@gmail.com>
Signed-off-by: NBen Chuang <ben.chuang@genesyslogic.com.tw>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NGrzegorz Kowal <custos.mentis@gmail.com>
Link: https://lore.kernel.org/r/20200504063957.6638-1-benchuanggli@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

If devm_request_threaded_irq() fails, the allocated struct mmc_host needs
to be freed via calling mmc_free_host(), so let's do that.

Fixes: c5413ad8 ("mmc: add new Alcor Micro Cardreader SD/MMC driver")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20200426202355.43055-1-christophe.jaillet@wanadoo.fr
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The kernel prints a message similar to
"[   28.881959] do_IRQ: 5.36 No irq handler for vector"
when GL975x resumes from suspend. Implement a resume callback to fix this.

Fixes: 31e43f31 ("mmc: sdhci-pci-gli: Enable MSI interrupt for GL975x")
Co-developed-by: NRenius Chen <renius.chen@genesyslogic.com.tw>
Signed-off-by: NRenius Chen <renius.chen@genesyslogic.com.tw>
Tested-by: NDave Flogeras <dflogeras2@gmail.com>
Signed-off-by: NBen Chuang <ben.chuang@genesyslogic.com.tw>
Tested-by: NVineeth Pillai <vineethrp@gmail.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200427103048.20785-1-benchuanggli@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: NSamuel Zou <zou_wei@huawei.com>
[Samuel Zou: Make sdhci_pci_gli_resume() static]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

BIOS writers have begun the practice of setting 40 ohm eMMC driver strength
even though the eMMC may not support it, on the assumption that the kernel
will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH
[offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid.

This is done to avoid changing the value for different boards.

Putting aside the merits of this approach, it is clear the eMMC's mask
of supported driver strengths is more reliable than the value provided
by BIOS. Add validation accordingly.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Fixes: 51ced59c ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200422111629.4899-1-adrian.hunter@intel.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

For some reason the Host Control2 register of the Xenon SDHCI controller
sometimes reports the bit representing 1.8V signaling as 0 when read
after it was written as 1. Subsequent read reports 1.

This causes the sdhci_start_signal_voltage_switch function to report
  1.8V regulator output did not become stable

When CONFIG_PM is enabled, the host is suspended and resumend many
times, and in each resume the switch to 1.8V is called, and so the
kernel log reports this message annoyingly often.

Do an empty read of the Host Control2 register in Xenon's
.voltage_switch method to circumvent this.

This patch fixes this particular problem on Turris MOX.
Signed-off-by: NMarek Behún <marek.behun@nic.cz>
Fixes: 8d876bf4 ("mmc: sdhci-xenon: wait 5ms after set 1.8V...")
Cc: stable@vger.kernel.org # v4.16+
Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.czSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

MSM sd host controller is capable of HW busy detection of device busy
signaling over DAT0 line. And it requires the R1B response for commands
that have this response associated with them.

So set the below two host capabilities for qcom SDHC.
 - MMC_CAP_WAIT_WHILE_BUSY
 - MMC_CAP_NEED_RSP_BUSY

Recent development of the mmc core in regards to this, revealed this as
being a potential bug, hence the stable tag.

Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: NVeerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1587363626-20413-2-git-send-email-vbadigan@codeaurora.orgSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>