According to the JEDEC specification, during bus timing change operations
for mmc, sending a CMD13 could trigger CRC errors.

As switching to HS DDR mode indeed causes a bus timing change, polling with
CMD13 to detect card busy, may thus potentially trigger CRC errors.
Currently these errors are treated as the switch to HS DDR mode failed.

To improve this behaviour, let's instead tell __mmc_switch() to retry when
it encounters CRC errors during polling.

Moreover, when switching to HS DDR mode, let's make sure the CMD13 polling
is done by having the mmc host and the mmc card, being configured to
operate at the same selected bus speed timing. Fix this by providing
MMC_TIMING_MMC_DDR52 as the timing parameter to __mmc_switch().
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>

In cases when the mmc host doesn't support HW busy detection, polling for a
card being busy by using CMD13 is beneficial. That is because, instead of
waiting a fixed amount of time, 500ms or the generic CMD6 time from
EXT_CSD, we find out a lot sooner when the card stops signaling busy. This
leads to a significant decreased total initialization time for the mmc
card.

However, to allow polling with CMD13 during a bus timing change operation,
such as switching to HS mode, we first need to update the mmc host's bus
timing before starting to poll. Deal with that, simply by providing
MMC_TIMING_MMC_HS as the timing parameter to __mmc_switch() from
mmc_select_hs().

By telling __mmc_switch() to allow polling with CMD13, also makes it
validate the CMD6 status, thus we can remove the corresponding checks.

When switching to HS400ES, the mmc_select_hs() function is called in one of
the intermediate steps. To still prevent CMD13 polling for HS400ES, let's
call the __mmc_switch() function in this path as it enables us to keep
using the existing method.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>

In cases when a speed mode change is requested for mmc cards, a CMD6 is
sent by calling __mmc_switch() during the card initialization. The CMD6
leads to the card entering a busy period. When that is completed, the host
must parse the CMD6 status to find out whether the change of the speed mode
succeeded.

To enable the mmc core to poll the card by using CMD13 to find out when the
busy period is completed, it's reasonable to make sure polling is done by
having the mmc host and the mmc card, being configured to operate at the
same selected bus speed timing.

Therefore, let's extend __mmc_switch() to take yet another parameter, which
allow its callers to update the bus speed timing of the mmc host. In this
way, __mmc_switch() also becomes capable of reading and validating the CMD6
status by sending a CMD13, in cases when that's desired.

If __mmc_switch() encounters a failure, we make sure to restores the old
bus speed timing for the mmc host, before propagating the error code.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>

Following changes needs mmc_switch_status() to be available both from mmc.c
and mmc_ops.c. Allow that by moving its implementation to mmc_ops.c and
make it available via mmc_ops.h.

Moving mmc_switch_status() to mmc_ops.c, also enables us to turn
mmc_switch_status_error() into static function. So let's take the
opportunity to change this as well.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>

In the eMMC 4.51 version of the spec, an EXT_CSD field called
GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum
time it may need to move out from its busy state, when a CMD6 command has
been sent.

In cases when the card is compliant to versions < 4.51 of the eMMC spec,
obviously the core needs to use a fall-back value for this timeout, which
currently is set to 10 minutes. This value is completely in the wrong range
and importantly in some cases it causes a card initialization to take more
than 10 minute to complete.

Earlier this scenario was avoided as the mmc core used CMD13 to poll the
card, to find out when it stopped signaling busy. Commit 08573eaf
("mmc: mmc: do not use CMD13 to get status after speed mode switch")
changed this behavior.

Instead of reverting that commit, which would cause other issues, let's
instead start by picking a simple solution for the problem, by using a
500ms default generic CMD6 timeout.

The reason for using exactly 500ms, comes from observations that shows it's
quite common for cards to specify 250ms. 500ms is two times that value so
likely it should be enough for most cards.

Cc: <stable@vger.kernel.org> # v4.8+
Fixes: 08573eaf ("mmc: mmc: do not use CMD13 to get status after speed
mode switch")
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NStephen Boyd <sboyd@codeaurora.org>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>

Per JESD84-B51 P49, Host need to change frequency to <=52MHz
after setting HS_TIMING to 0x1, and host may changes frequency
to <= 200MHz after setting HS_TIMING to 0x3. That means the card
expects the clock rate to increase from the current used f_init
(which is less than 400KHz, but still being less than 52MHz) to
52MHz, otherwise we find some eMMC devices significantly report
failure when sending status.
Reported-by: NXiao Yao <xiaoyao@rock-chips.com>
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

When introducing hs400es, I didn't notice that we haven't
switched voltage to 1V2 or 1V8 for it. That happens to work
as the first controller claiming to support hs400es, arasan(5.1),
which is designed to only support 1V8. So the voltage is fixed to 1V8.
But it actually is wrong, and will not fit for other host controllers.
Let's fix it.

Fixes: commit 81ac2af6 ("mmc: core: implement enhanced strobe support")
Cc: <stable@vger.kernel.org>
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The switch failure message in mmc_select_timing() had been removed
since that is invalid: commit 0400ed0a ("mmc: core: remove the
invalid message in mmc_select_timing")

Now, in the case when mmc_select_hs() return error in mmc_select_timing(),
there is nothing to print failure message.
Let's make for mmc_select_hs() print message itself in the failure case.
Signed-off-by: NJungseung Lee <js07.lee@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Export DSR register through sysfs same as we did for the CID, CSD and
OCR registers.
Signed-off-by: NBojan Prtvar <prtvar.b@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Registers CID and CSD are already exported through sysfs so let's make
this interface complete by adding missing OCR register.
Signed-off-by: NBojan Prtvar <prtvar.b@gmail.com>
Reviewed-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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

As some of the other features like BKOPs/Cache/Sanitize are dependent on
HPI feature, those features would also get disabled if HPI is disabled.
Signed-off-by: NPratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: NSubhash Jadavani <subhashj@codeaurora.org>
[gdavis: Forward port and cleanup]
Signed-off-by: NGeorge G. Davis <george_davis@mentor.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_select_bus_width() returns bus width (4 or 8) on success or
zero if unsupported. So only change mode if setting the bus width
is successful.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

To slove the issue which was found on gru board for hs400.

[    4.616946] sdhci: Secure Digital Host Controller Interface driver
[    4.623135] sdhci: Copyright(c) Pierre Ossman
[    4.722575] sdhci-pltfm: SDHCI platform and OF driver helper
[    4.730962] sdhci-arasan fe330000.sdhci: No vmmc regulator found
[    4.737444] sdhci-arasan fe330000.sdhci: No vqmmc regulator found
[    4.774930] mmc0: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA
[    4.980295] mmc0: switch to high-speed from hs200 failed, err:-84
[    4.986487] mmc0: error -84 whilst initialising MMC card

We should change HS400 mode selection timing to meet JEDEC
specification. The JEDEC 5.1 said that change the frequency to <= 52MHZ
after HS_TIMING switch. Refer to section 6.6.2.3 "HS400" timing mode
selection:
Set the "Timing Interface" parameter in the HS_TIMING[185] field of the
Extended CSD register to 0x1 to switch to High Speed mode and then set
the clock frequency to a value not greater than 52MHZ.
Signed-off-by: NZiyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Per JEDEC spec, it is not recommended to use CMD13 to get card status
after speed mode switch. below are two reason about this:
1. CMD13 cannot be guaranteed due to the asynchronous operation.
Therefore it is not recommended to use CMD13 to check busy completion
of the timing change indication.
2. After switch to HS200, CMD13 will get response of 0x800, and even the
busy signal gets de-asserted, the response of CMD13 is aslo 0x800.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Controllers use data strobe line to latch data from devices
under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
introduces enhanced strobe mode for latching cmd response from
emmc devices to host controllers. This new feature is optional,
so it depends both on device's cap and host's cap to decide
whether to use it or not.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.

Fix this by checking for a positive return value instead.

Fixes: 287980e4 ("remove lots of IS_ERR_VALUE abuses")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Tested-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.

This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.

Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.

I was using this definition for testing:

 #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
       unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.

I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.

[ Updated the 9p parts as per Al Viro  - Linus ]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some eMMCs set the partition switch timeout too low.

Now typically eMMCs are considered a critical component (e.g. because
they store the root file system) and consequently are expected to be
reliable.  Thus we can neglect the use case where eMMCs can't switch
reliably and we might want a lower timeout to facilitate speedy
recovery.

Although we could employ a quirk for the cards that are affected (if
we could identify them all), as described above, there is little
benefit to having a low timeout, so instead simply set a minimum
timeout.

The minimum is set to 300ms somewhat arbitrarily - the examples that
have been seen had a timeout of 10ms but were sometimes taking 60-70ms.

Cc: stable@vger.kernel.org
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_select_hs200() and mmc_select_hs() will keep the timing
as before if switch fails. So it's meaningless to print the
failed switched mode outside based on the current host timing.

Furthermore, the original print is wrong, it should be:
pr_warn("%s: switch to %s failed\n",
	mmc_hostname(card->host),
	mmc_card_hs(card) ? "high-speed" :
	(mmc_card_hs200(card) ? "hs200" : ""));

Since we already have error message in mmc_select_hs200(),
simply remove it outside.
Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently MMC core will keep going if HS200/HS timing switch failed
with -EBADMSG error by the assumption that the old timing is still valid.

However, for mmc_select_hs200 case, the signal voltage may have already
been switched. If the timing switch failed, we should fall back to
the old voltage in case the card is continue run with legacy timing.

If fall back signal voltage failed, we explicitly report an EIO error
to force retry during the next power cycle.
Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

CMD0 or hardware reset may invalidate the cache, so it needs to be
flushed before reset.

In the case of recovery, we can't expect flushing the cache to work
always, but have a go and ignore errors.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This if-block is going to call mmc_card_set_blockaddr(), so
mmc_card_blockaddr() right before it is redundant.

I am fixing the block comment style while I am here.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The eMMC HW reset may be implemented either via the host ops ->hw_reset()
callback or through DT and the eMMC pwrseq. Additionally some eMMC cards
don't support HW reset.

To allow a reset to be done for the different combinations of mmc hosts
and eMMC/MMC cards, let's implement a fallback via trying a regular power
cycle. This improves the mmc block layer retry mechanism of failing I/O
requests.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
[Ulf: Rewrote changelog]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The bus width is sometimes the actual bus width, and sometimes indices
to different arrays encoding the bus width. In my debugging case "2"
could mean 8-bit as well as 4-bit, which was extremly confusing. Let's
use the human-readable actual bus width in all places.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

IMO this info is only useful for developers. Most users won't need this
information, since there is not much they can do about it.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

A card can be removed while it is runtime suspended.
Do not print an error message.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Commit cc4f414c ("mmc: mmc: Add driver strength selection")
added driver strength selection for eMMC HS200 and HS400 modes.
That patch also set the driver stength when transitioning through
High Speed mode to HS200/HS400, but driver strength is not defined
for High Speed mode.  While the JEDEC specification is not clear
on this point it has been observed to cause problems for some eMMC,
and removing the driver strength setting in this case makes it
consistent with the normal use of High Speed mode.
Signed-off-by: NWenkai Du <wenkai.du@intel.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

MMC_CAP_RUNTIME_RESUME was invented to decrease system PM resume time for
systems that particularly needs this. As the feature has matured let's
make it the default behavior for MMC/SD.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_select_hs400() calls __mmc_switch() which checks the switch is
successful using CMD13 (SEND_STATUS).  The problem is that it does that
using the timing settings of the previous mode.  That is prone to error,
especially when switching from HS to HS400 because the timing parameters
for HS mode are tighter than the timing parameters for HS400 mode.

In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY)
with the switch command, it must be assumed that using different modes on
the card and host must work.

However in the case when CMD13 polling is not used
(i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs400() can be made more
reliable by setting the host to the correct timing before sending CMD13.

This patch does that.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org> # 4.2+
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Move the mmc_switch_status() function in preparation for calling it
in mmc_select_hs400().
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org> # 4.2+
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_select_hs400() begins with the card and host in HS200 mode.
Therefore, any commands sent to the card should use HS200 timing.
It is incorrect to set the host to High Speed (HS) timing before
sending the switch command.  Doing so is unreliable because
the timing parameters for HS mode are tighter than the timing
parameters for HS200 mode.  Thus the HS timings should be set
only after the card has switched mode.

However, it is not unreasonable first to reduce the frequency to
the HS mode frequency, which should make the switch command and
subsequent CMD13 commands more reliable.

This patch does that.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org> # 4.2+
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently mmc_select_hs200() uses __mmc_switch() which checks the
success of the switch to HS200 mode using CMD13 (SEND_STATUS).
The problem is that it does that using the timing settings of legacy
mode.  That is prone to error, not least because the timing parameters
for legacy mode are tighter than the timing parameters for HS200 mode.

In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY)
with the switch command, it must be assumed that using different modes on
the card and host must work.

However in the case when CMD13 polling is not used
(i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs200() can be made more
reliable by setting the host to the correct timing before sending CMD13.

This patch does that.

A complication is that the caller, mmc_select_timing(), will ignore a
switch error (indicated by -EBADMSG), assume the old mode is valid
and continue, so the old timing must be restored in that case.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org> # 4.2+
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

There's little sense in releasing the host on mmc_add_card() error
immediately after reclaiming  it, so reclaim the host  only in case
of success.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

MMC_CLKGATE was once invented to save power by gating the bus clock at
request inactivity. At that time it served its purpose. The modern way to
deal with power saving for these scenarios, is by using runtime PM.

Nowadays, several host drivers have deployed runtime PM, but for those
that haven't and which still cares power saving at request inactivity,
it's certainly time to deploy runtime PM as it has been around for several
years now.

To simplify code to mmc core and thus decrease maintenance efforts, this
patch removes all code related to MMC_CLKGATE.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

Suppose that we got a data crc error, and it triggers the mmc_reset.
mmc_reset will call mmc_send_status to see if HW reset was supported.
before issue CMD13, it will do retune, and if EMMC was in HS400 mode,
it will reduce frequency to 52Mhz firstly, then results in card init
was doing at 52Mhz.
The mmc_send_status was originally only done for mmc_test, should drop
it. And, rename the "eMMC hardware reset" to "Reset test", as we would
also be able to use the test for SD-cards.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Suggested-by: NAdrian Hunter <adrian.hunter@intel.com>
Fixes: bd11e8bd ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since the ->reset() callback is implemented for MMC, the ->power_restore()
callback has become redundant, let's remove it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add the ability to set eMMC driver strength
for HS200 and HS400.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In preparation for supporing drive strength selection
for eMMC, read the card's valid driver strengths.

Note that though the SD spec uses the term "drive strength",
the JEDEC eMMC spec uses the term "driver strength".
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

card->ext_csd.enhanced_area_offset is defined as "unsigned long long",
and, ext_csd[] is defined as u8.
unsigned long long data might have strange data if first bit of ext_csd[]
was 1. this patch cast it to (unsigned long long)
Special thanks to coverity <http://www.coverity.com>

ex)
        u8  data8;
        u64 data64;

        data8 = 0x80;
        data64 = (data8 << 24); // 0xffffffff80000000
        data64 = (((unsigned long long)data8) << 24); // 0x80000000;
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

HS400 re-tuning must be done in HS200 mode. Add
the ability to switch from HS400 mode to HS200
mode before re-tuning and switch back to HS400
after re-tuning.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>