mmc_select_hs400es() calls mmc_select_bus_width() which will continue
to set 4bit transfer mode if fail to set 8bit mode. The bus width
should not be set to 4bit in HS400es.

When fail to set 8bit mode, need return error directly for HS400es.
Signed-off-by: NHongjie Fang <hongjiefang@asrmicro.com>
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>

This adds two new HS400 tuning operations:
* hs400_downgrade
* hs400_complete

These supplement the existing HS400 operation:
* prepare_hs400_tuning

This is motivated by a requirement of Renesas SDHI for the following:
1. Disabling SCC before selecting to HS if selection of HS400 has occurred.
   This can be done in an implementation of prepare_hs400_tuning_downgrade
2. Updating registers after switching to HS400
   This can be done in an implementation of complete_hs400_tuning

If hs400_downgrade or hs400_complete are not implemented then they are not
called. Thus means there should be no affect for existing drivers as none
implemt these ops.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
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>

commit bfd694d5 ("mmc: core: Add tunable delay
before detecting card after card is inserted") adds
"u32 cd_debounce_delay_ms" to the last of mmc_gpio
struct and cause "char cd_label[0]" NOT work as string
pointer of card detect label, when "cat /proc/interrupts",
the devname for card detect gpio is incorrect as below:

144:          0  gpio-mxc  22 Edge      ▒
161:          0  gpio-mxc   7 Edge      ▒

Move the cd_label field down to fix this, and drop the
zero from the array size to prevent future similar bugs,
the result is correct as below:

144:          0  gpio-mxc  22 Edge      2198000.mmc cd
161:          0  gpio-mxc   7 Edge      2190000.mmc cd

Fixes: bfd694d5 ("mmc: core: Add tunable delay before detecting card after card is inserted")
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Tested-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.

[While this keeps existing behavior it seems to mismatch the comment,
 maintainers please chime in!]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

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>

This change uses the appropriate _cansleep or non-sleeping API for
reading GPIO card detect state. This allows users with GPIOs that
never sleep to avoid a warning when certain quirks are present.

The sdhci controller has an SDHCI_QUIRK_NO_CARD_NO_RESET, which
indicates that a controller will not reset properly if no card is
inserted. With this quirk enabled, mmc_get_cd_gpio is called in
several places with a spinlock held and interrupts disabled.
gpiod_get_raw_value_cansleep is not happy with this situation,
and throws out a warning.

For boards that a) use controllers that have this quirk, and b) wire
card detect up to a GPIO that doesn't sleep, this is a spurious warning.
This change silences that warning, at the cost of pushing this problem
down to users that have sleeping GPIOs and controllers with this quirk.
Signed-off-by: NEvan Green <evgreen@chromium.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Move the calls to ->prepare_hs400_tuning(), from mmc_retune() into
mmc_hs400_to_hs200(), as it better belongs there, rather than being generic
to all type of cards.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>

It's pointless to switch and trace partition type if the current
selected device partition is the same with that one. Moreover, cycled
claiming host associated with mmc_blk_part_switch() could make
mmc_blk_remove() end up waiting for grabbing the context if it's
occupied, which lead requests could still hit the low-level drivers,
if an asynchronous unbind for host drivers happened, as the card hasn't
been set removed in the remove path.

So a simple dd in background:
dd if=/dev/mmcblk0 of=/dev/null bs=512k count=100000 &

and doing unbind then:
echo fe320000.dwmmc > /sys/bus/platform/drivers/dwmmc_rockchip/unbind

could make the console stuck for quite a while depending on the
numbers of requests.
Suggested-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In commit 97548575 ("mmc: block: Convert RPMB to a character device") a
new function `mmc_rpmb_ioctl` was added. The final return is simply
returning a value of `0` instead of propagating the correct return code.

Discovered during a compilation with W=1, silence the following gcc warning

drivers/mmc/core/block.c:2470:6: warning: variable ‘ret’ set but not used
[-Wunused-but-set-variable]
Signed-off-by: NMathieu Malaterre <malat@debian.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Fixes: 97548575 ("mmc: block: Convert RPMB to a character device")
Cc: stable@vger.kernel.org # v4.15+
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>

Just set up the show callback in the tty_operations, and use
proc_create_single_data to create the file without additional
boilerplace code.
Signed-off-by: NChristoph Hellwig <hch@lst.de>

The limitation of being able to check only for -EPROBE_DEFER from
dev_pm_domain_attach() has been removed. Hence let's respect all error
codes and bail out accordingly.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Switch everyone to blk_get_request_flags, and then rename
blk_get_request_flags to blk_get_request.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

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

Let's implement the ->sw_reset() bus ops to allow SDIO func drivers, in
particular, to make a SW reset without doing a full power cycle of the SDIO
card.
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>

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>

The mmc_sdio_init_card() function has a couple of callers. In the
re-initialization cases, some additional reset commands are issued before
mmc_sdio_init_card() is called. As these additional reset commands are the
same, let's move these into a new static function, mmc_sdio_reinit_card()
and call mmc_sdio_init_card() from there. In this way we avoid the open
coding.
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>

Allow to use tunable delay before detecting card after card is inserted,
which either comes from firmware node, or comes from debounce value
passed on to mmc_gpiod_request_cd(). If the platform doesn't support
debounce, then we fall back to use the debounce period as the delay,
otherwise, it behaves the same as before that a HW debounce(if set) plus
a 200ms hardcode delay before detecting the card.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Some SD host controllers cannot handle extended use of 3.3V signaling.
To accommodate these controllers, add a capability that requires us to
negotiate the voltage down from 3.3V during card initialization.
Signed-off-by: NKyle Roeschley <kyle.roeschley@ni.com>
Signed-off-by: NJennifer Dahm <jennifer.dahm@ni.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch uses limit clock rate quirk to reduce clock rate
for "SDR104" mode on IMX side for Marvell 8887
WiFi + Bluetooth chip side, as Marvell does not recommend
to use SDIO at the speed of higher than 150MHz.
Signed-off-by: NDiwakar Sharma <diwakar.sharma@in.bosch.com>
Signed-off-by: NHarish Jenny K N <harish_kandiga@mentor.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch adds a quirk to limit clock rate which
can be used to reduce the SDIO clock rate for some
chips with broken UHS.
Signed-off-by: NHarish Jenny K N <harish_kandiga@mentor.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since RPMB area is accessible via special ioctl only and boot areas
are unlikely to contain any partitions, exclude them all from listing
in /proc/partitions. This will hide them from various user-level
software (e.g. fdisk), thus avoiding unnecessary access attempts.
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: NHarish Jenny K N <harish_kandiga@mentor.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The use of stack Variable Length Arrays needs to be avoided, as they
can be a vector for stack exhaustion, which can be both a runtime bug
(kernel Oops) or a security flaw (overwriting memory beyond the
stack). Also, in general, as code evolves it is easy to lose track of
how big a VLA can get. Thus, we can end up having runtime failures
that are hard to debug. As part of the directive[1] to remove all VLAs
from the kernel, and build with -Wvla.

Currently driver is using a VLA declared using the number of descriptors.  This
array is used to store integer values and is later used as an argument to
`gpiod_set_array_value_cansleep()` This can be avoided by using
`kmalloc_array()` to allocate memory for the array of integer values.  Memory is
free'd before return from function.

>From the code it appears that it is safe to sleep so we can use GFP_KERNEL
(based _cansleep() suffix of function `gpiod_set_array_value_cansleep()`.

It can be expected that this patch will result in a small increase in overhead
due to the use of `kmalloc_array()`

[1] https://lkml.org/lkml/2018/3/7/621Signed-off-by: NTobin C. Harding <me@tobin.cc>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Upon module load, mmc_block allocates a bus with bus_registeri() in
mmc_blk_init(). This reference never gets freed during module unload, which
leads to subsequent re-insertions of the module fails and a WARN() splat is
triggered.

Fix the bug by dropping the reference for the bus in mmc_blk_exit().
Signed-off-by: NAlexander Kappner <agk@godking.net>
Fixes: 97548575 ("mmc: block: Convert RPMB to a character device")
Cc: <stable@vger.kernel.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

dd if=/dev/urandom of=/dev/mmcblk1 bs=4k count=10000
with a SD card hotplug during transfer reports a warning below
introduced by commit a063057d ("block: Fix a race between
request queue removal and the block cgroup controller"). So we
should now remove the disk, partition and bdi sysfs attributes
before cleaning up the request queue associated with the disk.

[  410.331226] mmc1: card 59b4 removed
[  410.348583] WARNING: CPU: 0 PID: 5 at block/blk-core.c:785
blk_cleanup_queue+0x138/0x140
[  410.349294] Modules linked in:
[  410.349570] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted
4.16.0-rc6-next-20180321-00004-gc2ad6a7 #263
[  410.350363] Hardware name: Excavator-RK3399 Board (DT)
[  410.350819] Workqueue: events_freezable mmc_rescan
[  410.351242] pstate: 60000005 (nZCv daif -PAN -UAO)
[  410.351663] pc : blk_cleanup_queue+0x138/0x140
[  410.352054] lr : blk_cleanup_queue+0xac/0x140
[  410.352436] sp : ffff0000092cbb90
[  410.352727] x29: ffff0000092cbb90 x28: 0000000000000000
[  410.353195] x27: ffff8000f6f23030 x26: ffff00000904e610
[  410.353662] x25: ffff8000f17cc808 x24: ffff8000f1038200
[  410.354128] x23: 0000000000000060 x22: 0000000000000000
[  410.354595] x21: ffff8000f11748d8 x20: ffff8000f1038200
[  410.355061] x19: ffff8000f1174200 x18: 0000ffff936347d8
[  410.355528] x17: 0000ffff935b93c0 x16: ffff0000081263f8
[  410.355994] x15: 0000000000000000 x14: 0000000000000400
[  410.356461] x13: 0000000000000001 x12: 0000000000000001
[  410.356927] x11: 0000000000000040 x10: ffff8000f2400028
[  410.357393] x9 : ffff8000f2400040 x8 : 0000000000000000
[  410.357860] x7 : ffff8000f6f3a340 x6 : ffff8000f6f3a340
[  410.358326] x5 : ffff8000f2400000 x4 : ffff8000f6f3a340
[  410.358792] x3 : 0000000000000000 x2 : 39c1333e45670800
[  410.359259] x1 : 0000000000000000 x0 : 0000000000000003
[  410.359726] Call trace:
[  410.359943]  blk_cleanup_queue+0x138/0x140
[  410.360305]  mmc_cleanup_queue+0x2c/0x48
[  410.360652]  mmc_blk_remove_req+0x1c/0x98
[  410.361005]  mmc_blk_remove+0x180/0x1c0
[  410.361343]  mmc_bus_remove+0x1c/0x28
[  410.361670]  device_release_driver_internal+0x154/0x1f0
[  410.362128]  device_release_driver+0x14/0x20
[  410.362504]  bus_remove_device+0xc8/0x108
[  410.362858]  device_del+0x120/0x350
[  410.363167]  mmc_remove_card+0x5c/0xb8
[  410.363498]  mmc_sd_detect+0x40/0x78
[  410.363813]  mmc_rescan+0x19c/0x368
[  410.364123]  process_one_work+0x1ac/0x318
[  410.364477]  worker_thread+0x50/0x450
[  410.364801]  kthread+0xf8/0x128
[  410.365081]  ret_from_fork+0x10/0x18
[  410.365395] ---[ end trace 268e87a46c28968c ]---
Reviewed-by: NBart Van Assche <bart.vanassche@wdc.com>
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Update documentation for sdio_claim_irq to downgrade the wording
about doing recursive claims in an IRQ handler from 'must not' to
'should not'. This clarifies that recursive claims are supported,
but not the recommended (best) practice
Signed-off-by: NJoel Cunningham <joel.cunningham@garmin.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch exports the host capabilities to debugfs
Signed-off-by: NAbbas Raza <Abbas_Raza@mentor.com>
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
[Harish: Added caps2, moved creation to mmc_add_host_debugfs]
Signed-off-by: NHarish Jenny K N <harish_kandiga@mentor.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Certain Micron eMMC v4.5 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.

In U-Boot, these cards are reported as

Manufacturer: Micron (ID: 0xFE)
OEM: 0x4E
Name: MMC32G
Revision: 19 (0x13)
Serial: 959241022  Manufact. date: 8/2015 (0x82)  CRC: 0x00
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 29.1 GiB
Boot Partition Size: 16 MiB
Bus Width: 8-bit

According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by
Micron.
Signed-off-by: NDirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: NMark Craske <Mark_Craske@mentor.com>
Cc: <stable@vger.kernel.org> # 4.8+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the
currently active partition in mmc_blk_data->part_curr. These caches do
not always reflect changes if the ioctl call modifies the
PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE.

Write the PARTITION_CONFIG value extracted from the ioctl call to the
cache and update the currently active partition accordingly. This
ensures that the user space cannot change the values behind the
kernel's back. The next call to mmc_blk_part_switch() will operate on
the data set by the ioctl and reflect the changes appropriately.
Signed-off-by: NBastian Stender <bst@pengutronix.de>
Signed-off-by: NJan Luebbe <jlu@pengutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch exports RCA register to sysfs which will help in reading the
disk identification information.
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NHarish Jenny K N <harish_kandiga@mentor.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Certain Micron eMMC v4.5 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.

In U-Boot, these cards are reported as

Manufacturer: Micron (ID: 0xFE)
OEM: 0x4E
Name: MMC32G
Revision: 19 (0x13)
Serial: 959241022  Manufact. date: 8/2015 (0x82)  CRC: 0x00
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 29.1 GiB
Boot Partition Size: 16 MiB
Bus Width: 8-bit

According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by
Micron.
Signed-off-by: NDirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: NMark Craske <Mark_Craske@mentor.com>
Cc: <stable@vger.kernel.org> # 4.8+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the
currently active partition in mmc_blk_data->part_curr. These caches do
not always reflect changes if the ioctl call modifies the
PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE.

Write the PARTITION_CONFIG value extracted from the ioctl call to the
cache and update the currently active partition accordingly. This
ensures that the user space cannot change the values behind the
kernel's back. The next call to mmc_blk_part_switch() will operate on
the data set by the ioctl and reflect the changes appropriately.
Signed-off-by: NBastian Stender <bst@pengutronix.de>
Signed-off-by: NJan Luebbe <jlu@pengutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Variable err would be firstly initialized by the return value of
mmc_sd_switch().
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since we could move card->host->caps & MMC_CAP_4_BIT_DATA
ahead of mmc_sdio_init_uhs_card, in mmc_host_uhs(). So there
we could save this bit to check that. Also, if the process of
sdio_enable_4bit_bus goes wrong, we should bails out early.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Per SD specification physical layer v4.0, section 3.9.4, it
says "UHS-I supports only 4-bit mode. Host shall select 4-bit
mode by ACMD6. However mmc_sd_init_uhs_card() still go ahead
to initialize the cards anyway, whether card or host won't
support 4-bit mode.

  This breaks the platforms which could support UHS-I mode but on
some certain boards only support 1-bit mode with a UHS-I card inserted,
as all the tuning process is broken due to this. Alternatively, we
should check the return value from mmc_set_bus_width() to see if host
could finish the request to switch the bus width on its side. But that
needs more thing to do than this patch that just bails out early to try
high speed mode if 4-bit mode isn't available for whatever reason. And
this patch could also fix the same problem for sdio since R4_18V_PRESENT
won't be set for ocr when mmc_sdio_init_card() finds mmc_host_uhs()
is false.

  Note that this patch doesn't keep the checking of card->scr.sda_spec3
and comparing card->scr.bus_widths with SD_SCR_BUS_WIDTH_4 within
mmc_sd_init_uhs_card() since if the sd cards response with SD_ROCR_S18A,
it definitely supports UHS-I mode, which implicitly means these checkings
are always true.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>