commit e3ae3401aa upstream.
Some eMMCs from Micron have been reported to need ~800 ms timeout, while
enabling the CACHE ctrl after running sudden power failure tests. The
needed timeout is greater than what the card specifies as its generic CMD6
timeout, through the EXT_CSD register, hence the problem.
Normally we would introduce a card quirk to extend the timeout for these
specific Micron cards. However, due to the rather complicated debug process
needed to find out the error, let's simply use a minimum timeout of 1600ms,
the double of what has been reported, for all cards when enabling CACHE
ctrl.
Reported-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reported-by: Andreas Dannenberg <dannenberg@ti.com>
Reported-by: Faiz Abbas <faiz_abbas@ti.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ba9f39a785 upstream.
In commit 5320226a05 ("mmc: core: Disable HPI for certain Hynix eMMC
cards"), then intent was to prevent HPI from being used for some eMMC
cards, which didn't properly support it. However, that went too far, as
even BKOPS and CACHE ctrl became prevented. Let's restore those parts and
allow BKOPS and CACHE ctrl even if HPI isn't supported.
Fixes: 5320226a05 ("mmc: core: Disable HPI for certain Hynix eMMC cards")
Cc: Pratibhasagar V <pratibha@codeaurora.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0741ba40a upstream.
During a re-initialization of the eMMC card, we may fail to re-enable HPI.
In these cases, that isn't properly reflected in the card->ext_csd.hpi_en
bit, as it keeps being set. This may cause following attempts to use HPI,
even if's not enabled. Let's fix this!
Fixes: eb0d8f135b ("mmc: core: support HPI send command")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 486e666136 ]
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/621
Signed-off-by: Tobin C. Harding <me@tobin.cc>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit de8dcc3d2c ]
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: Daniel Drake <drake@endlessm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ebe7dd45cf upstream.
The block driver must be resumed if the mmc bus fails to suspend the card.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 5ef1ecf060 ]
Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
small DMA buffer not meeting this requirement.
When testing switching to descriptor chain mode in meson-gx driver
SDIO is broken therefore. Fix this by allocating the small DMA buffer
separately as kmalloc ensures that the returned memory area is
properly aligned for every basic data type.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Helmut Klein <hgkr.klein@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 92ddd95919 upstream.
Change the default err value to -EINVAL, make sure the card only
has type EXT_CSD_CARD_TYPE_HS400_1_8V also do the signal voltage
setting when select hs400es mode.
Fixes: commit 1720d3545b ("mmc: core: switch to 1V8 or 1V2 for hs400es mode")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 73a47a9bb3 upstream.
Using the device_property interfaces allows mmc drivers to work
on platforms which run on either device tree or ACPI.
Signed-off-by: David Woods <dwoods@mellanox.com>
Reviewed-by: Chris Metcalf <cmetcalf@mellanox.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 773dc11875 upstream.
HS400-ES devices fail to initialize with the following error messages.
mmc1: power class selection to bus width 8 ddr 0 failed
mmc1: error -110 whilst initialising MMC card
This was seen on Samsung Chromebook Plus. Code analysis points to
commit 3d4ef32975 ("mmc: core: fix multi-bit bus width without
high-speed mode"), which attempts to set the bus width for all but
HS200 devices unconditionally. However, for HS400-ES, the bus width
is already selected.
Cc: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Fixes: 3d4ef32975 ("mmc: core: fix multi-bit bus width ...")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chip.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d4ef32975 upstream.
Commit 577fb13199 ("mmc: rework selection of bus speed mode")
refactored bus width selection code to mmc_select_bus_width().
However, it also altered the behavior to not call the selection code in
non-high-speed modes anymore.
This causes 1-bit mode to always be used when the high-speed mode is not
enabled, even though 4-bit and 8-bit bus are valid bus widths in the
backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed
Modes in JEDEC 84-B50). This results in a significant regression in
transfer speeds.
Fix the code to allow 4-bit and 8-bit widths even without high-speed
mode, as before.
Tested with a Zynq-7000 PicoZed 7020 board.
Fixes: 577fb13199 ("mmc: rework selection of bus speed mode")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e85baa8868 upstream.
The mmc_read_ssr() function results in DMA to the raw_ssr member of
struct mmc_card, which is not guaranteed to be cache line aligned & thus
might not meet the requirements set out in Documentation/DMA-API.txt:
Warnings: Memory coherency operates at a granularity called the cache
line width. In order for memory mapped by this API to operate
correctly, the mapped region must begin exactly on a cache line
boundary and end exactly on one (to prevent two separately mapped
regions from sharing a single cache line). Since the cache line size
may not be known at compile time, the API will not enforce this
requirement. Therefore, it is recommended that driver writers who
don't take special care to determine the cache line size at run time
only map virtual regions that begin and end on page boundaries (which
are guaranteed also to be cache line boundaries).
On some systems where DMA is non-coherent this can lead to us losing
data that shares cache lines with the raw_ssr array.
Fix this by kmalloc'ing a temporary buffer to perform DMA into. kmalloc
will ensure the buffer is suitably aligned, allowing the DMA to be
performed without any loss of data.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 5275a652d2 ("mmc: sd: Export SD Status via “ssr” device attribute")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 08573eaf1a
("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: 08573eaf1a ("mmc: mmc: do not use CMD13 to get status after speed
mode switch")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: Linus 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: Xiao Yao <xiaoyao@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf 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 81ac2af657 ("mmc: core: implement enhanced strobe support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Per spec, block size should always be 512 bytes for dual rate mode,
so any attempts to switch the block size under dual rate mode should
be neglected.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
A host controller driver exposes its capability using caps flag
MMC_CAP_CMD_DURING_TFR. A driver with that capability can accept requests
that are marked mrq->cap_cmd_during_tfr = true. Then the driver informs the
upper layers when the command line is available for further commands by
calling mmc_command_done(). Because of that, the driver will not then
automatically send STOP commands, and it is the responsibility of the upper
layer to send a STOP command if it is required.
For requests submitted through the mmc_wait_for_req() interface, the caller
sets mrq->cap_cmd_during_tfr = true which causes mmc_wait_for_req() in fact
not to wait. The caller can then send commands that do not use the data
lines. Finally the caller can wait for the transfer to complete by calling
mmc_wait_for_req_done() which is now exported.
For requests submitted through the mmc_start_req() interface, the caller
again sets mrq->cap_cmd_during_tfr = true, but mmc_start_req() anyway does
not wait. The caller can then send commands that do not use the data
lines. Finally the caller can wait for the transfer to complete in the
normal way i.e. calling mmc_start_req() again.
Irrespective of how a cap_cmd_during_tfr request is started,
mmc_is_req_done() can be called if the upper layer needs to determine if
the request is done. However the appropriate waiting function (either
mmc_wait_for_req_done() or mmc_start_req()) must still be called.
The implementation consists primarily of a new completion
mrq->cmd_completion which notifies when the command line is available for
further commands. That completion is completed by mmc_command_done().
When there is an ongoing data transfer, calls to mmc_wait_for_req() will
automatically wait on that completion, so the caller does not have to do
anything special.
Note, in the case of errors, the driver may call mmc_request_done() without
calling mmc_command_done() because mmc_request_done() always calls
mmc_command_done().
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In most cases the 'card->erase_size' is power of 2, then the round_up/down()
function is more efficient than '%' operation when the 'card->erase_size' is
power of 2.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to clean up the mmc_erase() function and do some optimization
for erase size alignment, factor out the guts of erase size alignment
into mmc_align_erase_size() function.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In cases when the host->max_busy_timeout isn't specified, the calculated
number of maximum discard sectors defaults to UINT_MAX. This may cause a
too long timeout for a discard request.
Avoid this by using a default maximum erase timeout of 60s, used when we
calculate the maximum number of sectors that are allowed to be discarded
per request.
Do note that the minimum number of sectors to be discarded is still at
least one "preferred erase size".
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
When using mmc_io_rw_extended, it's intent to avoid null
pointer of card and invalid func number. But actually it
didn't prevent that as the seg_size already use the card.
Currently the wrapper function sdio_io_rw_ext_helper already
use card before calling mmc_io_rw_extended, so we should move
this check to there. As to the func number, it was token from
'(ocr & 0x70000000) >> 28' which should be enough to guarantee
that it won't be larger than 7. But we should prevent the
caller like wifi drivers modify this value. So let's move this
check into sdio_io_rw_ext_helper either.
Also we remove the BUG_ON for mmc_send_io_op_cond since all
possible paths calling this function are protected by checking
the arguments in advance. After deploying these changes, we
could not see any panic within SDIO API even if func drivers
abuse the SDIO func APIs.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The switch failure message in mmc_select_timing() had been removed
since that is invalid: commit 0400ed0a08 ("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: Jungseung Lee <js07.lee@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The SD Status register contains several important fields related to the
SD Card proprietary features.
Those fields may be used by user space applications for vendor specific
usage.
None of those fields are exported today by the driver to user space.
In this patch, we are reading the SD Status register and exporting
(using MMC_DEV_ATTR) the SD Status register to the user space.
Signed-off-by: Uri Yanai <uri.yanai@sandisk.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some devices need a while to boot their firmware after providing clks /
de-asserting resets before they are ready to receive sdio commands.
This commits adds a post-power-on-delay-ms devicetree property to
mmc-pwrseq-simple for use with such devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When mmc host HW supports busy signalling (using R1B as response), don't
use the host->max_busy_timeout as the limitation when deciding the max
discard sectors, which we inform the generic BLOCK layer about. Instead,
let's use at least one preferred erase size as the max discard sectors.
In cases when the host controller supports HW busy signalling and the
timeout for the erase operation doesn't exceed the max_busy_timeout, we
keep the R1B response, otherwise we prevent the host from doing HW busy
detection by converting to a R1 response.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Export DSR register through sysfs same as we did for the CID, CSD and
OCR registers.
Signed-off-by: Bojan Prtvar <prtvar.b@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The reason for why we expose these to dt is that some of
the controller is unable to send special cmd type due to
the hw limitation.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf 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: Bojan Prtvar <prtvar.b@gmail.com>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Host drivers which needs to valdiate for non-supported MMC
commands and returnn error code for such requests.
To improve and simplify the behaviour, let's invent MMC_CAP2_NO_MMC
which these host drivers can set to tell the mmc core to skip sending MMC
commands during card initialization.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
There are host drivers which needs to valdiate for non-supported SD
commands and returnn error code for such requests.
To improve and simplify the behaviour, let's invent MMC_CAP2_NO_SD
which these host drivers can set to tell the mmc core to skip sending SD
commands during card initialization.
Signed-off-by: Ulf 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: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
[gdavis: Forward port and cleanup]
Signed-off-by: George G. Davis <george_davis@mentor.com>
Signed-off-by: Ulf 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: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If available, eMMC stack uses HC_ERASE_GRP_SIZE as the preferred erase
size. As some high capacity eMMC (64MB) reports this size to 512kB, the
discard operations end up taking very long time.
Improve the behaviour by instead calculating the preferred erase size
based on the eMMC size. In this way the discard operations becomes faster.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
[Ulf: Updated changelog and improved comment in code]
Signed-off-by: Ulf 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: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
with CONFIG_HZ=100, the precision of jiffies is 10ms, and the
generic_cmd6_time of some card is also 10ms. then, may be current
time is only 5ms, but already timed out caused by jiffies precision.
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: Ulf 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: Chaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some MMC hosts do not support MMC_CAP_WAIT_WHILE_BUSY, but implements the
->card_busy() callback. In such cases, extend __mmc_switch() to use this
method to check card status after switch command.
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We introduce HS400 with enhanced strobe function, so we need
to add it for debug show.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf 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: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This patch introduce mmc-hs400-enhanced-strobe for platforms
which want to enable enhanced strobe function from DT if the
mmc host controller claims to support enhanced strobe.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf 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: 287980e49f ("remove lots of IS_ERR_VALUE abuses")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Ulf 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: Arnd 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: Linus Torvalds <torvalds@linux-foundation.org>
008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.
This patch will...
() Increase the long read time quirk timeout from 300ms to 600ms. Original
author of that quirk says 300ms was only a guess and that the number
may need to be raised in the future.
() Add this specific MMC to the quirk
Signed-off-by: Matt Gumbel <matthew.k.gumbel@intel.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Re-tuning is not possible when switched to the RPMB
partition. However re-tuning should not be needed
if re-tuning is done immediately before switching,
a small set of operations is done, and then we
immediately switch back to the main partition.
To ensure that re-tuning can't be done for a short
while, add a facility to "pause" re-tuning.
The existing facility to hold / release re-tuning
is used but it also flags re-tuning as needed to cause
re-tuning before the next command (which will be the
switch to RPMB).
We also need to "unpause" in the recovery path, which
is catered for by adding it to mmc_retune_disable().
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.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: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
I have two SDIO WLAN cards which specify being SDIO Rev. 1.1 cards but
their FUNCE tuple reports the smaller size of a Rev 1.0 card. So,
enforce 1.0 on these cards to avoid reading the not present registers.
They are not really used anyhow. My cards initialize properly after this
patch.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf 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: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf 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: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
