mmc: core: constify the struct device_type usage

Since commit aed65af1cc2f ("drivers: make device_type const"), the driver
core can properly handle constant struct device_type. Move the sdio_type,
sd_type and mmc_type variables to be constant structures as well, placing
it into read-only memory which can not be modified at runtime.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Link: https://lore.kernel.org/r/20240219-device_cleanup-mmc-v1-1-1910e283cf5a@marliere.net
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Add host specific tuning support for SD HS mode

To support the need for host specific tuning for SD high-speed mode, let's
add two new optional callbacks, ->prepare|execute_sd_hs_tuning() and let's
call them when switching into the SD high-speed mode.

Note that, during the tuning process it's also needed for host drivers to
send commands to the SD card to verify that the tuning process succeeds.
Therefore, let's also share the corresponding functions from the core to
allow this.

Signed-off-by: Wenchao Chen <wenchao.chen@unisoc.com>
Link: https://lore.kernel.org/r/20230825091743.15613-2-wenchao.chen@unisoc.com
[Ulf: Dropped unnecessary function declarations and updated the commit msg]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: Add MMC_QUIRK_BROKEN_SD_CACHE for Kingston Canvas Go Plus from 11/2019

This microSD card never clears Flush Cache bit after cache flush has
been started in sd_flush_cache(). This leads e.g. to failure to mount
file system. Add a quirk which disables the SD cache for this specific
card from specific manufacturing date of 11/2019, since on newer dated
cards from 05/2023 the cache flush works correctly.

Fixes: 08ebf903af57 ("mmc: core: Fixup support for writeback-cache for eMMC and SD")
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20230620102713.7701-1-marex@denx.de
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Normalize the error handling branch in sd_read_ext_regs()

Let's use pr_err() to output the error messages and let's extend a comment
to clarify why returning 0 (success) in one case make sense.

Fixes: c784f92769ae ("mmc: core: Read the SD function extension registers for power management")
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
[Ulf: Clarified the comment and the commit-msg]
Link: https://lore.kernel.org/r/20221130134920.2109-1-thunder.leizhen@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Terminate infinite loop in SD-UHS voltage switch

This loop intends to retry a max of 10 times, with some implicit
termination based on the SD_{R,}OCR_S18A bit. Unfortunately, the
termination condition depends on the value reported by the SD card
(*rocr), which may or may not correctly reflect what we asked it to do.

Needless to say, it's not wise to rely on the card doing what we expect;
we should at least terminate the loop regardless. So, check both the
input and output values, so we ensure we will terminate regardless of
the SD card behavior.

Note that SDIO learned a similar retry loop in commit 0797e5f1453b
("mmc: core: Fixup signal voltage switch"), but that used the 'ocr'
result, and so the current pre-terminating condition looks like:

rocr & ocr & R4_18V_PRESENT

(i.e., it doesn't have the same bug.)

This addresses a number of crash reports seen on ChromeOS that look
like the following:

... // lots of repeated: ...
<4>[13142.846061] mmc1: Skipping voltage switch
<4>[13143.406087] mmc1: Skipping voltage switch
<4>[13143.964724] mmc1: Skipping voltage switch
<4>[13144.526089] mmc1: Skipping voltage switch
<4>[13145.086088] mmc1: Skipping voltage switch
<4>[13145.645941] mmc1: Skipping voltage switch
<3>[13146.153969] INFO: task halt:30352 blocked for more than 122 seconds.
...

Fixes: f2119df6b764 ("mmc: sd: add support for signal voltage switch procedure")
Cc: <stable@vger.kernel.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20220914014010.2076169-1-briannorris@chromium.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Fix inconsistent sd3_bus_mode at UHS-I SD voltage switch failure

If re-initialization results is a different signal voltage, because the
voltage switch failed previously, but not this time (or vice versa), then
sd3_bus_mode will be inconsistent with the card because the SD_SWITCH
command is done only upon first initialization.

Fix by always reading SD_SWITCH information during re-initialization, which
also means it does not need to be re-read later for the 1.8V fixup
workaround.

Note, brief testing showed SD_SWITCH took about 1.8ms to 2ms which added
about 1% to 1.5% to the re-initialization time, so it's not particularly
significant.

Reported-by: Seunghui Lee <sh043.lee@samsung.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Seunghui Lee <sh043.lee@samsung.com>
Tested-by: Seunghui Lee <sh043.lee@samsung.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220815073321.63382-3-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Fix UHS-I SD 1.8V workaround branch

When introduced, upon success, the 1.8V fixup workaround in
mmc_sd_init_card() would branch to practically the end of the function, to
a label named "done". Unfortunately, perhaps due to the label name, over
time new code has been added that really should have come after "done" not
before it. Let's fix the problem by moving the label to the correct place
and rename it "cont".

Fixes: 045d705dc1fb ("mmc: core: Enable the MMC host software queue for the SD card")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Seunghui Lee <sh043.lee@samsung.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220815073321.63382-2-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Use mmc_card_* macro and add a new for the sd_combo type

Add mmc_card_sd_combo() macro for sd combo type card and use the mmc_card_*
macro to simplify code instead of comparing card->type.

Signed-off-by: Seunghui Lee <sh043.lee@samsung.com>
Link: https://lore.kernel.org/r/20220713033635.28432-2-sh043.lee@samsung.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Replace with already defined values for readability

SD_ROCR_S18A is already defined and is used to check the rocr value, so
let's replace with already defined values for readability.

Signed-off-by: ChanWoo Lee <cw9316.lee@samsung.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220706004840.24812-1-cw9316.lee@samsung.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Add CIDs for cards to the entropy pool

To make the entropy pool a bit better we can toss in the
CID for eMMC and SD cards into it, usually the serial
number portion is at least unique.

This does not count as improvement of the entropy but
in practice it makes it a bit more random to mix in these
numbers.

Cc: Theodore Ts'o <tytso@mit.edu>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220425205442.1347837-1-linus.walleij@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: use sysfs_emit() instead of sprintf()

sprintf() (still used in the MMC core for the sysfs output) is vulnerable
to the buffer overflow. Use the new-fangled sysfs_emit() instead.

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.

Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/717729b2-d65b-c72e-9fac-471d28d00b5a@omp.ru
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND

Commit 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1"),
significantly decreased the polling period from ~10-12ms into just a couple
of us. The purpose was to decrease the total time spent in the busy polling
loop, but unfortunate it has lead to problems, that causes eMMC cards to
never gets out busy and thus fails to be initialized.

To fix the problem, but also to try to keep some of the new improved
behaviour, let's start by using a polling period of 1-2ms, which then
increases for each loop, according to common polling loop in
__mmc_poll_for_busy().

Reported-by: Jean Rene Dawin <jdawin@math.uni-bielefeld.de>
Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Huijin Park <huijin.park@samsung.com>
Fixes: 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jean Rene Dawin <jdawin@math.uni-bielefeld.de>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/20220304105656.149281-1-ulf.hansson@linaro.org

mmc: core: Wait for command setting 'Power Off Notification' bit to complete

SD card is allowed to signal busy on DAT0 up to 1s after the
CMD49. According to SD spec (version 6.0 section 5.8.1.3) first host
waits until busy of CMD49 is released and only then polls Power
Management Status register up to 1s until the card indicates ready to
power off.

Without waiting for busy before polling status register sometimes card
becomes unresponsive and system fails to suspend:

[ 205.907459] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 206.421274] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[ 206.421321] sunxi-mmc 1c0f000.mmc: send stop command failed
[ 206.421347] mmc0: error -110 reading status reg of PM func
[ 206.421366] PM: dpm_run_callback(): mmc_bus_suspend+0x0/0x74 returns -110
[ 206.421402] mmcblk mmc0:aaaa: PM: failed to suspend async: error -110
[ 206.437064] PM: Some devices failed to suspend, or early wake event detected

Tested with Sandisk Extreme PRO A2 64GB on Allwinner A64 system.

Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Fixes: 2c5d42769038 ("mmc: core: Add support for Power Off Notification for SD cards")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220115121447.641524-1-andrej.skvortzov@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: change __mmc_poll_for_busy() parameter type

This patch changes the __mmc_poll_for_busy() first parameter type
from 'struct mmc_card*' to 'struct mmc_host*'.
Because the function refers only 'struct mmc_host' to get hostname.

Signed-off-by: Huijin Park <huijin.park@samsung.com>
Link: https://lore.kernel.org/r/20211104063231.2115-2-huijin.park@samsung.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

block: move struct request to blk-mq.h

struct request is only used by blk-mq drivers, so move it and all
related declarations to blk-mq.h.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Link: https://lore.kernel.org/r/20210920123328.1399408-18-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>

mmc: core: Allow UHS-I voltage switch for SDSC cards if supported

While initializing an UHS-I SD card, the mmc core first tries to switch to
1.8V I/O voltage, before it continues to change the settings for the bus
speed mode.

However, the current behaviour in the mmc core is inconsistent and doesn't
conform to the SD spec. More precisely, an SD card that supports UHS-I must
set both the SD_OCR_CCS bit and the SD_OCR_S18R bit in the OCR register
response. When switching to 1.8V I/O the mmc core correctly checks both of
the bits, but only the SD_OCR_S18R bit when changing the settings for bus
speed mode.

Rather than actually fixing the code to confirm to the SD spec, let's
deliberately deviate from it by requiring only the SD_OCR_S18R bit for both
parts. This enables us to support UHS-I for SDSC cards (outside spec),
which is actually being supported by some existing SDSC cards. Moreover,
this fixes the inconsistent behaviour.

Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
Link: https://lore.kernel.org/r/CWXP265MB26803AE79E0AD5ED083BF2A6C4529@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM
Cc: stable@vger.kernel.org
[Ulf: Rewrote commit message and comments to clarify the changes]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Add support for cache ctrl for SD cards

In SD spec v6.x the SD function extension registers for performance
enhancements were introduced. As a part of this an optional internal cache
on the SD card, can be used to improve performance.

The let the SD card use the cache, the host needs to enable it and manage
flushing of the cache, so let's add support for this.

Note that for an SD card supporting the cache it's mandatory for it, to
also support the poweroff notification feature. According to the SD spec,
if the cache has been enabled and a poweroff notification is sent to the
card, that implicitly also means that the card should flush its internal
cache. Therefore, dealing with cache flushing for REQ_OP_FLUSH block
requests is sufficient.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Link: https://lore.kernel.org/r/20210511101359.83521-1-ulf.hansson@linaro.org

mmc: core: Add support for Power Off Notification for SD cards

Rather than only deselecting the SD card via a CMD7, before we cut power to
it at system suspend, at runtime suspend or at shutdown, let's add support
for a graceful power off sequence via enabling the SD Power Off
Notification feature.

Note that, the Power Off Notification feature was added in the SD spec
v4.x, which is several years ago. However, it's still a bit unclear how
often the SD card vendors decides to implement support for it. To validate
these changes a Sandisk Extreme PRO A2 64GB has been used, which seems to
work nicely.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://lore.kernel.org/r/20210504161222.101536-12-ulf.hansson@linaro.org

mmc: core: Read performance enhancements registers for SD cards

In SD spec v6.x the SD function extension registers for performance
enhancements were introduced. These registers let the SD card announce
supports for various performance related features, like "self-maintenance",
"cache" and "command queuing".

Let's extend the parsing of SD function extension registers and store the
information in the struct mmc_card. This prepares for subsequent changes to
implement the complete support for new the performance enhancement
features.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://lore.kernel.org/r/20210504161222.101536-11-ulf.hansson@linaro.org

mmc: core: Read the SD function extension registers for power management

In the SD spec v4.0 the CMD48/49 and CMD58/59 were introduced as optional
commands. In the SD spec v4.1 the SD function extension registers were
introduced, which requires support for CMD48/49/58/59 to be read/written
from/to.

Moreover, a specific function extension register were added to let the card
announce support for optional features in regards to power management. The
features that were added are "Power Off Notification", "Power Down Mode"
and "Power Sustenance".

As a first step to support this, let's read and parse the register for
power management during the SD card initialization and store the
information about the supported features in the struct mmc_card. In this
way, we prepare for subsequent changes to implement the complete support
for the new features.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Avri Altman <avri.altman@wdc.com>
Link: https://lore.kernel.org/r/20210504161222.101536-10-ulf.hansson@linaro.org

mmc: core: Parse the SD SCR register for support of CMD48/49 and CMD58/59

In SD spec v4.x the support for CMD48/49 and CMD58/59 were introduced as
optional features. To let the card announce whether it supports the
commands, the SCR register has been extended with corresponding support
bits. Let's parse and store this information for later use.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Avri Altman <avri.altman@wdc.com>
Link: https://lore.kernel.org/r/20210504161222.101536-9-ulf.hansson@linaro.org

mmc: core: Set read only for SD cards with permanent write protect bit

Some of SD cards sets permanent write protection bit in their CSD register,
due to lifespan or internal problem. To avoid unnecessary I/O write
operations, let's parse the bits in the CSD during initialization and mark
the card as read only for this case.

Signed-off-by: Seunghui Lee <sh043.lee@samsung.com>
Link: https://lore.kernel.org/r/20210222083156.19158-1-sh043.lee@samsung.com
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: remove unused host parameter of mmc_sd_get_csd()

The host parameter is not used in the body of mmc_sd_get_csd(),
so let's remove it. Update related code at the same time.

Signed-off-by: Yue Hu <huyue2@yulong.com>
Link: https://lore.kernel.org/r/20210118084520.241-1-zbestahu@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: sd: Use kobj_to_dev() instead of container_of()

Use kobj_to_dev() instead of container_of()

Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Link: https://lore.kernel.org/r/1598230956-58523-1-git-send-email-tiantao6@hisilicon.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: sdio: Export SDIO revision and info strings to userspace

For SDIO functions, SDIO cards and SD COMBO cards are exported revision
number and info strings from CISTPL_VERS_1 structure. Revision number
should indicate compliance of standard and info strings should contain
product information in same format as product information for PCMCIA cards.

Product information for PCMCIA cards should contain following strings in
this order: Manufacturer, Product Name, Lot number, Programming Conditions.

Note that not all SDIO cards export all those info strings in that order as
described in PCMCIA Metaformat Specification.

Signed-off-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20200727133837.19086-5-pali@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Export device/vendor ids from Common CIS for SDIO cards

Device/vendor ids from Common CIS (Card Information Structure) may be
different as device/vendor ids from CIS on particular SDIO function.

Kernel currently exports only device/vendor ids from SDIO functions and not
"main" device/vendor ids from Common CIS.

This patch exports "main" device/vendor ids for SDIO and SD combo cards at
top level mmc device in sysfs hierarchy.

Userspace can use e.g. udev rules to correctly match whole SDIO card based
on Common CIS device/vendor id and not only one particular SDIO function.
Having this information in userspace also helps developers to debug whole
SDIO card as e.g. kernel mmc quirks use device/vendor ids from Common CIS
and not from particular SDIO function. Also it allows to write userspace
applications which list all connected SDIO cards based on CIS ids.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Link: https://lore.kernel.org/r/20200527110858.17504-2-pali@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: sd: use HIGH_SPEED_BUS_SPEED in mmc_sd_switch_hs()

Use the well defined HIGH_SPEED_BUS_SPEED macro in mmc_sd_switch_hs()
to make code more readable.

Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200410145643.630b0731@xhacker.debian
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Enable the MMC host software queue for the SD card

Enable the MMC host software queue for the SD card if the host controller
supports the MMC host software queue.

On my Spreadtrum platform, I did not see any obvious performance changes
in 4K block size when changing to use hsq for the SD cards, I think the
reason is the SD card works at a low speed on my platform, and most of
time is spent in the hardware. But we can see some obvious improvements
when enabling the packed request based on hsq, that's why we still add hsq
support for the SD cards.

Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/0065b4631fef2d61c3b89d14a4ea4f2b7499ea56.1581478568.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Fix init of SD cards reporting an invalid VDD range

The OCR register defines the supported range of VDD voltages for SD cards.
However, it has turned out that some SD cards reports an invalid voltage
range, for example having bit7 set.

When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from
the invalid VDD range, this triggers the core to run a power cycle of the
card to try to initialize it at the lowest common supported voltage.
Obviously this fails, since the card can't support it.

Let's fix this problem, by clearing invalid bits from the read OCR register
for SD cards, before proceeding with the VDD voltage negotiation.

Cc: stable@vger.kernel.org
Reported-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Philip Langdale <philipl@overt.org>
Tested-by: Philip Langdale <philipl@overt.org>
Tested-by: Manuel Presnitz <mail@mpy.de>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

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

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

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: core: Verify SD bus width

The SD Physical Layer Spec says the following: Since the SD Memory Card
shall support at least the two bus modes 1-bit or 4-bit width, then any SD
Card shall set at least bits 0 and 2 (SD_BUS_WIDTH="0101").

This change verifies the card has specified a bus width.

AMD SDHC Device 7806 can get into a bad state after a card disconnect
where anything transferred via the DATA lines will always result in a
zero filled buffer. Currently the driver will continue without error if
the HC is in this condition. A block device will be created, but reading
from it will result in a zero buffer. This makes it seem like the SD
device has been erased, when in actuality the data is never getting
copied from the DATA lines to the data buffer.

SCR is the first command in the SD initialization sequence that uses the
DATA lines. By checking that the response was invalid, we can abort
mounting the card.

Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Add a debug print when the card may have been replaced

If the card was removed in suspended state and a new one was inserted,
print a debug log when the check detects that it's not the old card.

Signed-off-by: hongjiefang <hongjiefang@asrmicro.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Add discard support to sd

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

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

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

One more important difference compared to ERASE is the busy timeout
which we will address on the next patch.

Signed-off-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Indicate SD specs higher than 4.0

SD specs version 4.x and 5.x have a dedicated slices in the SCR register.
Higher versions will rely on a combination of the existing fields.

Signed-off-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Calculate the discard arg only once

In MMC, the discard arg is a read-only ext_csd parameter - set it once
on card init. To be consistent, do that for SD as well even though its
discard arg is always 0x0.

Signed-off-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Rename ->reset() bus ops to ->hw_reset()

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: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Quentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

mmc: core: Add capability to avoid 3.3V signaling

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: Kyle Roeschley <kyle.roeschley@ni.com>
Signed-off-by: Jennifer Dahm <jennifer.dahm@ni.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Export card RCA register via sysfs

This patch exports RCA register to sysfs which will help in reading the
disk identification information.

Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: sd: Remove redundant err assignment from mmc_read_switch

Variable err would be firstly initialized by the return value of
mmc_sd_switch().

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Don't try UHS-I mode if 4-bit mode isn't supported

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: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: prepend 0x to OCR entry in sysfs

The sysfs entry "ocr" was missing the 0x prefix to identify it as hex
formatted.

Fixes: 5fb06af7a33b ("mmc: core: Extend sysfs with OCR register")
Signed-off-by: Bastian Stender <bst@pengutronix.de>
Cc: <stable@vger.kernel.org> # v4.8+
[Ulf: Amended change to also cover SD-cards]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: sd: Fix signal voltage when there is no power cycle

Some boards have SD card connectors where the power rail cannot be switched
off by the driver. However there are various circumstances when a card
might be re-initialized, such as after system resume, warm re-boot, or
error handling. However, a UHS card will continue to use 1.8V signaling
unless it is power cycled.

If the card has not been power cycled, it may still be using 1.8V
signaling. According to the SD spec., the Bus Speed Mode (function group 1)
bits 2 to 4 are zero if the card is initialized at 3.3V signal level. Thus
they can be used to determine if the card has already switched to 1.8V
signaling. Detect that situation and try to initialize a UHS-I (1.8V)
transfer mode.

Tested with the following cards:
Transcend 4GB High Speed
Kingston 64GB SDR104
Lexar by Micron HIGH-PERFORMANCE 300x 16GB DDR50
SanDisk Ultra 8GB DDR50
Transcend Ultimate 600x 16GB SDR104
Transcend Premium 300x 64GB SDR104
Lexar by Micron Professional 1000x 32GB UHS-II SDR104
SanDisk Extreme Pro 16GB SDR104

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Zhoujie Wu <zjwu@marvell.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Introduce host claiming by context

Currently the host can be claimed by a task. Change this so that the host
can be claimed by a context that may or may not be a task. This provides
for the host to be claimed by a block driver queue to support blk-mq, while
maintaining compatibility with the existing use of mmc_claim_host().

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: correct taac parameter according to the specification

Per the spec of JESD84-B51, section 7.3, replace tacc with taac to
fix the obvious typo.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Re-factor code for sending CID

Instead of having the caller to check for SPI mode, let's leave that to
internals of mmc_send_cid(). In this way the code gets cleaner and it
becomes clear what is specific to SPI and non-SPI mode.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

mmc: core: Delete error messages for failed memory allocations

Omit an extra message for memory allocation failures.

This issue was detected by using the Coccinelle software.

Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: add proper be32 annotation

Annotate big endian values correctly and make sparse happy.
In mmc_app_send_scr remove scr function parameter as it was
updating card->raw_scr anyway.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Clarify usage of mmc_set_signal_voltage()

The mmc_set_signal_voltage() function is used for SD/SDIO when switching to
1.8V for UHS mode. To clarify this let's do the following changes.

- We are always providing MMC_SIGNAL_VOLTAGE_180 as the signal_voltage
parameter to the function. Then, let's just remove the parameter as it
serves no purpose.
- Rename the function to mmc_set_uhs_voltage().

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Jan Glauber <jglauber@cavium.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>

mmc: core: Move public functions from host.h to private headers

A significant amount of functions are available through the public mmc
host.h header file. Let's slim down this public mmc interface, as to
prevent users from abusing it, by moving some of the functions to private
mmc host.h header file.

This change concentrates on moving the functions into private mmc headers,
following changes may continue with additional clean-ups.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

mmc: core: Move public functions from card.h to private headers

A significant amount of functions and other definitions are available
through the public mmc card.h header file. Let's slim down this public mmc
interface, as to prevent users from abusing it, by moving some of the
functions/definitions to private mmc header files.

This change concentrates on moving the functions into private mmc headers,
following changes may continue with additional clean-ups.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

mmc: sd: Meet alignment requirements for raw_ssr DMA

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: 5275a652d296 ("mmc: sd: Export SD Status via “ssr” device attribute")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: remove BUG_ONs from sd

BUG_ONs doesn't help anything except for stop the system from
running. If it occurs, it implies we should deploy proper error
handling for that. So this patch is gonna discard these meaningless
BUG_ONs and deploy error handling if needed.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: sd: Export SD Status via “ssr” device attribute

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>

mmc: core: Extend sysfs with DSR register

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>

mmc: core: Extend sysfs with OCR register

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>

mmc: core: remove redundant memset of mmc_decode_cid

When initializing sd or sdio card, we get struct mmc_card
from mmc_alloc_card which allocates it by kzalloc. So we don't
need another memset while decoding cid.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Enable tuning according to the actual timing

While in sdhci_execute_tuning() the choice whether or not to enable the
tuning is done on the actual timing, in the mmc_sdio_init_uhs_card() the
check is done on the capability of the card.

This difference is causing some issues with some SDIO cards in DDR50
mode where the CDM19 is wrongly issued.

With this patch we modify the check in both
mmc_(sd|sdio)_init_uhs_card() functions to take the proper decision
only according to the actual timing specification.

Cc: stable@vger.kernel.org
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: sd: limit SD card power limit according to cards capabilities

The SD card specification allows cards to error out a SWITCH command
where the requested function in a group is not supported. The spec
provides for a set of capabilities which indicate which functions are
supported.

In the case of the power limit, requesting an unsupported power level
via the SWITCH command fails, resulting in the power level remaining at
the power-on default of 0.72W, even though the host and card may support
higher powers levels.

This has been seen with SanDisk 8GB cards, which support the default
0.72W and 1.44W (200mA and 400mA) in combination with an iMX6 host,
supporting up to 2.88W (800mA). This currently causes us to try to set
a power limit function value of '3' (2.88W) which the card errors out
on, and thereby causes the power level to remain at 0.72W rather than
the desired 1.44W.

Arrange to limit the selected current limit by the capabilities reported
by the card to avoid the SWITCH command failing. Select the highest
current limit that the host and card combination support.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fixes: a39ca6ae0a08 ("mmc: core: Simplify and fix for SD switch processing")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: It is not an error for the card to be removed while suspended

A card can be removed while it is runtime suspended.
Do not print an error message.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Make runtime resume default behavior for MMC/SD

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: Ulf Hansson <ulf.hansson@linaro.org>

mmc: skip reclaiming host on mmc_add_card() error

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: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Remove MMC_CLKGATE

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: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

mmc: core: enable CMD19 tuning for DDR50 mode

As SD Specifications Part1 Physical Layer Specification Version
3.01 says, CMD19 tuning is available for unlocked cards in transfer
state of 1.8V signaling mode. The small difference between v3.00
and 3.01 spec means that CMD19 tuning is also available for DDR50
mode.

Signed-off-by: Weijun Yang <york.yang@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: sd: Remove superfluous error code assignment

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Remove redundant ->power_restore() callback for SD

Since the ->reset() callback is implemented for SD, the ->power_restore()
callback has become redundant, let's remove it.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Record card drive strength

In preparation for adding drive strength support
for eMMC, add drive_strength to struct mmc_card
to record the card drive strength for UHS-I modes
and HS200 / HS400. For eMMC this will be needed
when switching between HS200 and HS400.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Factor out common code in drive strength selection

Make a new function out of common code used for drive
strength selection.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Add 'card' to drive strength selection callback

In preparation for supporting also eMMC drive strength,
add the 'card' as a parameter so that the callback can
distinguish different types of cards if necessary.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Simplify card drive strength mask

Card drive strength selection uses a callback to
which a mask of supported drive strengths is passed.
Currently, the bits are checked against the values
in the SD specifications. That is not necessary
because the callback will anyway match the mask
against a valid value. Simplify by taking the mask
as is but still ensuring that the default mandatory
value (type B) is always supported.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Allow card drive strength to be different to host

Initialization of UHS-I modes for SD and SDIO cards
employs a callback to allow the host driver to
choose a drive strength value. Currently that
assumes the card drive strength and host driver
type must be the same value. Change to let the
callback make that decision and return both the
card drive strength and host driver type.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: Add support for disabling write-protect detection

It is not uncommon to see systems where there is no physical write-protect
signal (e.g. when using eMMC or microSD card slots). For some controllers,
which have a dedicated write-protection detection logic (like SDHCI
controllers), the get_ro() callback can return bogus data in such a case.

Instead of handling this on a per controller basis this patch adds a new
capability flag to the MMC core that can be set to specify that the result
of get_ro() is invalid. When the flag is set the core will not call
get_ro() and assume that the card is always read-write.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

treewide: Fix typo in printk messages

This patch fix spelling typo in printk messages.

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

mmc: core: Simplify by adding mmc_execute_tuning()

For each MMC, SD and SDIO there is code that
holds the clock, calls ops->execute_tuning, and
releases the clock. Simplify the code a bit by
providing a separate function to do that.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: sd: add reset bus_ops callback

Enable power cycle and re-initialization of SD cards via the reset
bus_ops. Power cycling a buggy SD card sometimes helps it get back on
track.

Signed-off-by: Johan Rudholm <johanru@axis.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Support the optional init_card() callback for MMC and SD

In (3fcb027 ARM: MXC: mxcmmc: work around a bug in the SDHC busy line
handling) the optional init_card() callback was added. According to
the original change it was "for now only called from
mmc_sdio_init_card()".

This callback really ought to be called from the SD and MMC init
functions as well. One current user of this callback
(mxcmci_init_card) will not work as expected if you insert an SDIO
card, then eject it and put a normal SD card in. Specifically the
normal SD card will not get to run with 4-bit data.

I'd like to use the init_card() callback to handle a similar quirk on
dw_mmc when using SDIO Interrupts (the "low power" feature of the card
needs to be disabled), so that will add a second user of the function.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: Convert pr_warning to pr_warn

Use the much more common pr_warn instead of pr_warning.

Other miscellanea:

o Coalesce formats
o Realign arguments
o Remove extra spaces when coalescing formats

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: implement Driver Stage Register handling

Some eMMC and SD cards implement a DSR register that allows to tune
raise/fall times and drive strength of the CMD and DATA outputs.
The values to use depend on the card in use and the host.
It might be needed to reduce the drive strength to prevent voltage peaks
above the host's specification.

Implement a 'dsr' devicetree property that allows to specify the value
to set the DSR to. For non-dt setups the new members of mmc_host can be
set by board code.

This patch was initially authored by Sascha Hauer. It contains
improvements authored by Markus Niebel and Uwe Kleine-König.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: drop the speed mode of card's state

Timing mode identifier has same role and can take the place
of speed mode. This change removes all related speed mode.

Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

mmc: Convert to use ATTRIBUTE_GROUPS

Use new ATTRIBUTE_GROUPS macro to declare attribute groups.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

mmc: core: Use MMC_UNSAFE_RESUME as default behavior

Invoking system suspend or shutdown without using the Kconfig option
MMC_UNSAFE_RESUME, did trigger an ungraceful power cut of the card.

To improve the situation, change the behavior to always make use of the
available bus_ops callbacks that handles system suspend and shutdown
properly.

By changing the behavior MMC_UNSAFE_RESUME becomes redundant, so lets's
remove it.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

mmc: core: sd: implement proper support for sd3.0 au sizes

This reverts and updates commit 77776fd0a4cc541b9 ("mmc: sd: fix the
maximum au_size for SD3.0"). The au_size for SD3.0 cannot be achieved
by a simple bit shift, so this needs to be implemented differently.
Also, don't print the warning in case of 0 since 'not defined' is
different from 'invalid'.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: stable <stable@vger.kernel.org> # [3.12, 3.13]
Signed-off-by: Chris Ball <chris@printf.net>

mmc: core: Add MMC_CAP_RUNTIME_RESUME to resume at runtime_resume

In some environments it is to prefer to postpone the resume of the card
device until runtime_resume is being carried out, since it will mean a
signficant decrease of the total system resume time.

The reason of the decreased resume time is simply because of the actual
re-initalization of the card, which typically takes hundreds of
milliseconds, is performed outside the resume sequence and wont thus
affect it.

For removable card, the detect work tries to re-detect the card to make
sure it is still present, as a part of that sequence the card will also
be runtime_resumed and thus also fully resumed.

For a non-removable card, typically a mmc blk request will trigger a
runtime_resume and thus fully resume the card. This also means the
first request will likely suffer from an inital latency since the
re-initialization of the card needs to be performed.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Improve runtime PM support during suspend/resume for sd/mmc

The card device is considered as in-active after it has been suspended.
To prevent any further runtime PM requests in suspend state, we then
disable runtime PM.

After the card device has been resumed, we shall consider it as active,
like we also do after a probe sequence. When resumed, we can safely
enable runtime PM again.

This will make sure the PM core can request the card device to go to
in-active state after a resume has been completed. Previously we had to
wait for new pm_runtime_get->pm_runtime_put cycle to be executed.

Additionally, once a resume has been carried out, update the last busy
mark. At the moment this will have no effect but if the PM core will
respect autosuspend enabled devices, when it directly triggers a
runtime_suspend from a runtime_idle, it will mean the card device will
be scheduled for a delayed runtime_suspend instead of done immediately.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Remove redundant mmc_power_up|off at runtime callbacks

Commit "mmc: core: Push common suspend|resume code into each bus_ops"
moved the responsibility for doing mmc_power_up|off into each
suspend/resume bus_ops. When using MMC_CAP_AGGRESSIVE_PM, through the
runtime callbacks, calls to mmc_power_up|off became redundant.

When removing them, we are also able to remove the calls to
mmc_claim|release_host, thus simplifing code a bit more.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: Don't force card to active state when entering suspend/shutdown

By adding a card state that records if it is suspended or resumed, we
can accept asyncronus suspend/resume requests for the mmc and sd
bus_ops.

MMC_CAP_AGGRESSIVE_PM, will at request inactivity through the runtime
bus_ops callbacks, execute a suspend of the the card. In the state were
this has been done, we can receive a suspend request for the mmc bus,
which for sd and mmc forced the card to active state by a
pm_runtime_get_sync. In other words, the card was resumed and then
immediately suspended again, completely unnecessary.

Since the suspend/resume bus_ops callbacks for sd and mmc are now
capable of handling asynchronous requests, we no longer need to force
the card to active state before executing suspend. Evidently preventing
the above sequence for MMC_CAP_AGGRESSIVE_PM.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Collect common code for card ocr validation

Since mmc_select_voltage now only gets called from the attach sequence,
it makes sense to move the out of spec validations of the card ocr into
this function.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Prevent violation of specs while initializing cards

According to eMMC/SD/SDIO specs, the VDD (VCC) voltage level must be
maintained during the initialization sequence. If we want/need to tune
the voltage level, a complete power cycle of the card must be executed.

Most host drivers conforms to the specifications by only allowing to
change VDD voltage level at the MMC_POWER_UP state, but some also cares
about MMC_POWER_ON state, which they should'nt. This patch will not
break those drivers, but they could clean up code to better reflect
what is expected from the protocol layer.

A big re-work of the mmc_select_voltage function is done to only change
VDD voltage level if the host supports MMC_CAP2_FULL_PWR_CYCLE.
Otherwise only validation of the host and card ocr mask will be done.

A very nice side-effect of this patch is that we now don't need to
reset the negotiated ocr mask at the mmc_power_off function, since now
it will actually reflect the present voltage level, which safely can be
used at the next power up and re-initialization. Moreover, we then only
need to execute mmc_select_voltage from the attach sequence.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Move cached value of the negotiated ocr mask to card struct

The negotiated ocr mask is directly related to the card. Once a card
gets removed, the mask shall be dropped. By moving the cache of the ocr
mask from the host struct to the card struct we have accomplished this.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Let mmc_set_signal_voltage take ocr as parameter

This is yet another step of restructure code to be able to fixup the
setup of the negotiated ocr mask.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Let mmc_power_up|cycle take ocr as parameter

As a step to fixup the setup of the negotiated ocr mask, we need the
mmc_power_up|cycle functions to take the ocr as a parameter.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: fix the maximum au_size for SD3.0

Since SD Physical Layer specification V3.0, AU_SIZE is supported up
to 0xf. So If SD-card is supported v3.0, then max_au should be 0xf.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: free mmc_card if cmd 3,9,7 fails in mmc_sd_init_card

In function mmc_sd_init_card, if command 3/9/7 got failed, mmc_card
allocated just before won't be freed. This would cause memory leak.

Signed-off-by: Wei WANG <wei_wang@realsil.com.cn>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Add shutdown callback for SD bus_ops

For the SD .shutdown callback we re-use the SD suspend function since
it performs the relevant actions.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Push common suspend|resume code into each bus_ops

By moving code from the mmc_suspend|resume_host down into each
.suspend|resume bus_ops callback, we get a more flexible solution.

Some nice side effects are that we get a better understanding of each
bus_ops suspend|resume sequence and the common code don't have to take
care of specific corner cases, especially for the SDIO case.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Support aggressive power management for (e)MMC/SD

Aggressive power management is suitable when saving power is
essential. At request inactivity timeout, aka pm runtime
autosuspend timeout, the card will be suspended.

Once a new request arrives, the card will be re-initalized and
thus the first request will suffer from a latency. This latency
is card-specific, experiments has shown in general that SD-cards
has quite poor initialization time, around 300ms-1100ms. eMMC is
not surprisingly far better but still a couple of hundreds of ms
has been observed.

Except for the request latency, it is important to know that
suspending the card will also prevent the card from executing
internal house-keeping operations in idle mode. This could mean
degradation in performance.

To use this feature make sure the request inactivity timeout is
chosen carefully. This has not been done as a part of this patch.

Enable this feature by using host cap MMC_CAP_AGGRESSIVE_PM and
by setting CONFIG_MMC_UNSAFE_RESUME.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: block: Enable runtime pm for mmc blkdevice

Once the mmc blkdevice is being probed, runtime pm will be enabled.
By using runtime autosuspend, the power save operations can be done
when request inactivity occurs for a certain time. Right now the
selected timeout value is set to 3 s. Obviously this value will likely
need to be configurable somehow since it needs to be trimmed depending
on the power save algorithm.

For SD-combo cards, we are still leaving the enablement of runtime PM
to the SDIO init sequence since it depends on the capabilities of the
SDIO func driver.

Moreover, when the blk device is being suspended, we make sure the device
will be runtime resumed. The reason for doing this is that we want the
host suspend sequence to be unaware of any runtime power save operations
done for the card in this phase. Thus it can just handle the suspend as
the card is fully powered from a runtime perspective.

Finally, this patch prepares to make it possible to move BKOPS handling
into the runtime callbacks for the mmc bus_ops. Thus IDLE BKOPS can be
accomplished.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Only execute tuning for SDR50 and SDR104

Only execute tuning for sd and sdio devices that are using
SDR50 or SDR104.

Make sure clock is hold during tuning for sdio devices.

Signed-off-by: Fredrik Soderstedt <fredrik.soderstedt@stericsson.com>
Acked-by: Johan Rudholm <jrudholm@gmail.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sdhci: enhance preset value function

4d55c5a1 ("mmc: sdhci: enable preset value after uhs initialization")
added preset value support and enabled it by default during sd card init.

Below are the enhancements introduced by this patch:

1. In current code, preset value is enabled after setting clock finished,
which means the clock is manually set by driver firstly and then suddenly
switched to preset value at this point. So the first setting is useless
and unnecessary. What's more, the first clock setting may differ from the
preset one. The better way is enable preset value just after switch to
UHS mode so the preset value can take effect immediately. So move preset
value enable from mmc_sd_init_card to sdhci_set_ios which will be called
during set timing.

2. In current code, preset value is disabled at the beginning of
mmc_attach_sd. It's too late since low freq (400khz) should be set in
mmc_power_up. So move preset value disable to sdhci_set_ios which will
be called during power up.

3. host->clock and ios->drv_type should also be updated according to the
preset value if it's enabled. Current code missed this.

4. This patch also introduce a quirk to disable preset value in case
preset value doesn't work.

This patch has been verified on sdhci-pxav3 platform with both preset
enabled and disabled.

Signed-off-by: Kevin Liu <kliu5@marvell.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Fixup signal voltage switch

When switching SD and SDIO cards from 3.3V to 1.8V signal levels, the
clock should be gated for 5 ms during the step. After enabling the
clock, the host should wait for at least 1 ms before checking for
failure. Failure by the card to switch is indicated by dat[0:3] being
pulled low. The host should check for this condition and power-cycle
the card if failure is indicated.

Add a retry mechanism for the SDIO case.

If the voltage switch fails repeatedly, give up and continue the
initialization using the original voltage.

This patch places a couple of requirements on the host driver:

1) mmc_set_ios with ios.clock = 0 must gate the clock
2) mmc_power_off must actually cut the power to the card
3) The card_busy host_ops member must be implemented

if these requirements are not fulfilled, the 1.8V signal voltage switch
will still be attempted but may not be successful.

Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Wei WANG <wei_wang@realsil.com.cn>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Break out start_signal_voltage_switch

Allow callers to access the start_signal_voltage_switch host_ops
member without going through any cmd11 logic. This is mostly a
preparation for the following signal voltage switch patch.

Also, reset ios.signal_voltage to its original value if
start_signal_voltage_switch fails.

Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Wei WANG <wei_wang@realsil.com.cn>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: Simplify by using mmc_host_uhs

Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: reset signal voltage on power up

Add a call to mmc_set_signal_voltage() to set signal voltage to 3.3v in
mmc_power_up so that we do not need to touch signal voltage setting in
mmc/sd/sdio init functions and rescan function.

For mmc/sd cards, when doing a suspend/resume cycle, consider the unsafe
resume case, the card will lose its power and when powered on again, we
will set signal voltage to 3.3v in mmc_power_up before its resume function
gets called, which will re-init the card.

And for sdio cards, when doing a suspend/resume cycle, consider the unsafe
resume case, the card will either lose its power or not depending on if it
wants to wakeup the host. If power is not maintained, it is the same case as
mmc/sd cards. If power is maintained, mmc_power_up will not be called and
the card's signal voltage will remain at the last setting.

Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Tested-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: Fix sd current limit setting

Host has different current capabilities at different voltages, we need
to record these settings seperately. The defined voltages are 1.8/3.0/3.3.
For other voltages, we do not touch current limit setting.

Before we set the current limit for the sd card, find out the host's
operating voltage first and then find out the current capabilities of
the host at that voltage to set the current limit.

Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Simplify and fix for SD switch processing

In mmc_read_switch, just do a one time mode 0 switch command to get the
support bits information, no need to do multiple times as the support
bits do not change with different arguments.

And no need to check current limit support bits, as these bits are
fixed according to the signal voltage. If the signal voltage is 1.8V,
the support bits would be 0xf and if the signal voltage is 3.3V, the
support bits would be 0x01. We will check host's ability to set the
current limit.

Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: correct invalid error checking

The effect of the existing code is that we continue blindly when we
should warn about an invalid allocation unit.

Reported-by: dcb314@hotmail.com
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44061
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sdhci: only set 200mA support for 1.8v if 200mA is available

max_current_caps can return 0 if not available from the sd controller.
If no regulator is present or the regulator specifies a current
less then 200ma, we no longer still set the 200mA caps bit anyway.

Signed-off-by: Philip Rakity <prakity@marvell.com>
Reviewed-by: Aaron Lu <aaron_lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: return an error on suspend if mmc_deselect_cards fails

When mmc_host is not spi mode, mmc/sd is doing mmc_deselect_cards().
mmc_deselect_cards could be returned error.
If returned error, we can know something wrong when enter suspend.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Fixup suspend/resume issues for UHS-I cards

Even if cards supports 1.8V I/O voltage those should anyway be
initialized at 3.3V I/O according to (e)MMC, SD and SDIO specs.
Some eMMC and embedded SDIO devices are able to be initialized
at 1.8V as well, but it is better to be safe.

Do note that initialization in this context means that the card
has been completely powered off, otherwise the card will remain
at the last I/O voltage level that were negotitiated.

Due to the above being taken care of the suspend/resume issues
for UHS-I SD-cards has been fixed.

Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Acked-by: Philip Rakity <prakity@marvell.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Ensure clocks are always enabled before host interaction

Ensure clocks are always enabled before any interaction with the
host controller driver. This makes sure that there is no race
between host execution and the core layer turning off clocks
in different context with clock gating framework.

Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Per Forlin <per.forlin@stericsson.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: HS200 mode support for eMMC 4.5

This patch adds the support of the HS200 bus speed for eMMC 4.5 devices.
The eMMC 4.5 devices have support for 200MHz bus speed. The function
prototype of the tuning function is modified to handle the tuning
command number which is different in sd and mmc case.

Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: allow upper layers to know immediately if card has been removed

Add a function mmc_detect_card_removed() which upper layers can use to
determine immediately if a card has been removed. This function should
be called after an I/O request fails so that all queued I/O requests
can be errored out immediately instead of waiting for the card device
to be removed.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sdio: support SDIO UHS cards

This patch adds support for sdio UHS cards per the version 3.0
spec.

UHS mode is only enabled for version 3.0 cards when both the
host and the controller support UHS modes.

1.8v signaling support is removed if both the card and the
host do not support UHS. This is done to maintain
compatibility and some system/card combinations break when
1.8v signaling is enabled when the host does not support UHS.

Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Aaron Lu <Aaron.lu@amd.com>
Reviewed-by: Arindam Nath <arindam.nath@amd.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: Macro name cleanup for high speed dtr

Add new macros for the high speed 50MHz case, rather than having
a confusing reuse of the value for UHS SDR50, which is 100MHz.

Reported-by: Aaron Lu <aaron.lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: Fix implicit use of stat.h header in associated files

Once the implicit use of module.h is prevented, these files will
fail to find the stat.h header content.

Fix up the implicit usage expectations in advance of the cleanup.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

mmc: sd: Handle SD3.0 cards not supporting UHS-I bus speed mode

Here is Essential conditions to indicate Version 3.00 Card
(SD_SPEC=2 and SD_SPEC3=1) :
(1) The card shall support CMD6
(2) The card shall support CMD8
(3) The card shall support CMD42
(4) User area capacity shall be up to 2GB (SDSC) or 32GB (SDHC)
User area capacity shall be more than or equal to 32GB and
up to 2TB (SDXC)
(5) Speed Class shall be supported (SDHC or SDXC)

So even if SD card doesn't support any of the newly defined
UHS-I bus speed mode, it can advertise itself as SD3.0 cards
as long as it supports all the essential conditions of
SD3.0 cards. Given this, these type of cards should atleast
run in High Speed mode @50MHZ if it supports HS.

But current initialization sequence for SD3.0 cards is
such that these non-UHS-I SD3.0 cards runs in Default
Speed mode @25MHz.

This patch makes sure that these non-UHS-I SD3.0 cards run
in High Speed Mode @50MHz.

Tested this patch with SanDisk Extreme SDHC 8GB Class 10 card.

Reported-by: "Hiremath, Vaibhav" <hvaibhav@ti.com>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: replace printk with appropriate display macro

All the files using printk function for displaying kernel messages
in the mmc driver have been replaced with corresponding macro.

Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Set correct bus mode before card init

Earlier all cards where initiated with bus mode set as OPENDRAIN, and then
later switched to PUSHPULL. According to the MMC/SD/SDIO specifications
only MMC cards use OPENDRAIN during init. For both SD and SDIO the bus
mode shall be PUSHPULL before attempting to init the card.

The consequence of having incorrect bus mode can lead to not being able
to detect the card. Therefore the default behavior have now been changed
to PUSHPULL in mmc_power_up, and will only be temporarily switched when
trying to attach or init a MMC card.

Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
Signed-off-by: Ulf HANSSON <ulf.hansson@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Fix hangs related to insert/remove of cards

During a rescan operation mmc_attach(sd|mmc|sdio) functions are
called. The error handling in these function can trigger a detach
of the bus, which also meant a power off. This is not notified by
the rescan operation which then continues to the next attach function.

If a power off has been done, the framework must never send any
new commands to the host driver, without first doing a new power up.
This will most likely trigger any host driver to hang.

Moving power off out of detach and instead handle power off
separately when it is actually needed, solves the issue.

Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: <stable@kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: UHS-I bus speed should be set last in UHS initialization

mmc_sd_init_uhs_card function sets the driver type, current limit
and bus speed mode on card as well as on host controller side.

Currently bus speed mode is set by sending CMD6 to card and
immediately setting the timing mode in host controller. But
then before initiating tuning sequence, it also tries to set
current limit by sending CMD6 to card which results in data
timeout errors in controller if bus speed mode is SDR50/SDR104 mode.

So basically bus speed mode should be set only after current limit
is set in the card and immediately after setting the bus speed mode,
tuning sequence should be initiated.

Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Arindam Nath <arindam.nath@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Set non-default Drive Strength via platform hook

Non default Drive Strength cannot be set automatically. It is a function
of the board design and only if there is a specific platform handler can
it be set. The platform handler needs to take into account the board
design. Pass to the platform code the necessary information.

For example: The card and host controller may indicate they support HIGH
and LOW drive strength. There is no way to know what should be chosen
without specific board knowledge. Setting HIGH may lead to reflections
and setting LOW may not suffice. There is no mechanism (like ethernet
duplex or speed pulses) to determine what should be done automatically.

If no platform handler is defined -- use the default value.

Signed-off-by: Philip Rakity <prakity@marvell.com>
Reviewed-by: Arindam Nath <arindam.nath@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: Block CMD23 support for UHS104/SDXC cards.

SD cards operating at UHS104 or better support SET_BLOCK_COUNT.

Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
Reviewed-by: Arindam Nath <arindam.nath@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: eMMC signal voltage does not use CMD11

eMMC chips do not use CMD11 when changing voltage. Add extra
argument to call to indicate if CMD11 needs to be sent.

Signed-off-by: Philip Rakity <prakity@marvell.com>
Reviewed-by: Arindam Nath <arindam.nath@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sdhci: enable preset value after uhs initialization

According to the Host Controller spec v3.00, setting Preset Value Enable
in the Host Control2 register lets SDCLK Frequency Select, Clock Generator
Select and Driver Strength Select to be set automatically by the Host
Controller based on the UHS-I mode set. This patch enables this feature.
Since Preset Value Enable makes sense only for UHS-I cards, we enable this
feature after successfull UHS-I initialization. We also reset Preset Value
Enable next time before initialization.

Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.

Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: add support for tuning during uhs initialization

Host Controller needs tuning during initialization to operate SDR50
and SDR104 UHS-I cards. Whether SDR50 mode actually needs tuning is
indicated by bit 45 of the Host Controller Capabilities register.
A new command CMD19 has been defined in the Physical Layer spec
v3.01 to request the card to send tuning pattern.

We enable Buffer Read Ready interrupt at the very begining of tuning
procedure, because that is the only interrupt generated by the Host
Controller during tuning. We program the block size to 64 in the
Block Size register. We make sure that DMA Enable and Multi Block
Select in the Transfer Mode register are set to 0 before actually
sending CMD19. The tuning block is sent by the card to the Host
Controller using DAT lines, so we set Data Present Select (bit 5) in
the Command register. The Host Controller is responsible for doing
the verfication of tuning block sent by the card at the hardware
level. After sending CMD19, we wait for Buffer Read Ready interrupt.
In case we don't receive an interrupt after the specified timeout
value, we fall back on fixed sampling clock by setting Execute
Tuning (bit 6) and Sampling Clock Select (bit 7) of Host Control2
register to 0. Before exiting the tuning procedure, we disable Buffer
Read Ready interrupt and re-enable other interrupts.

Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.

Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: report correct speed and capacity of uhs cards

Since only UHS-I cards respond with S18A set in response to ACMD41,
we set the card as ultra-high-speed after successfull initialization.
We need to decide whether a card is SDXC based on the C_SIZE field
of CSDv2.0 register. According to Physical Layer spec v3.01, the
minimum value of C_SIZE for SDXC card is 00FFFFh.

Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.

Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: set current limit for uhs cards

We decide on the current limit to be set for the card based on the
Capability of Host Controller to provide current at 1.8V signalling,
and the maximum current limit of the card as indicated by CMD6
mode 0. We then set the current limit for the card using CMD6 mode 1.
As per the Physical Layer Spec v3.01, the current limit switch is
only applicable for SDR50, SDR104, and DDR50 bus speed modes. For
other UHS-I modes, we set the default current limit of 200mA.

Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.

Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: add support for uhs bus speed mode selection

This patch adds support for setting UHS-I bus speed mode during UHS-I
initialization procedure. Since both the host and card can support
more than one bus speed, we select the highest speed based on both of
their capabilities. First we set the bus speed mode for the card using
CMD6 mode 1, and then we program the host controller to support the
required speed mode. We also set High Speed Enable in case one of the
UHS-I modes is selected. We take care to reset SD clock before setting
UHS mode in the Host Control2 register, and then re-enable it as per
the Host Controller spec v3.00. We then set the clock frequency for
the UHS-I mode selected.

Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.

Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: add support for driver type selection

This patch adds support for setting driver strength during UHS-I
initialization procedure. Since UHS-I cards set S18A (bit 24) in
response to ACMD41, we use this as a base for UHS-I initialization.
We modify the parameter list of mmc_sd_get_cid() so that we can
save the ROCR from ACMD41 to check whether bit 24 is set.

We decide whether the Host Controller supports A, C, or D driver
type depending on the Capabilities register. Driver type B is
suported by default. We then set the appropriate driver type for
the card using CMD6 mode 1. As per Host Controller spec v3.00, we
set driver type for the host only if Preset Value Enable in the
Host Control2 register is not set. SDHCI_HOST_CONTROL has been
renamed to SDHCI_HOST_CONTROL1 to conform to the spec.

Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.

Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: query function modes for uhs cards

SD cards which conform to Physical Layer Spec v3.01 can support
additional Bus Speed Modes, Driver Strength, and Current Limit
other than the default values. We use CMD6 mode 0 to read these
additional card functions. The values read here will be used
during UHS-I initialization steps.

Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.

Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sd: add support for signal voltage switch procedure

Host Controller v3.00 adds another Capabilities register. Apart
from other things, this new register indicates whether the Host
Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec
doesn't mention about explicit support for SDR12 and SDR25 UHS-I
modes, so the Host Controller v3.00 should support them by default.
Also if the controller supports SDR104 mode, it will also support
SDR50 mode as well. So depending on the host support, we set the
corresponding MMC_CAP_* flags. One more new register. Host Control2
is added in v3.00, which is used during Signal Voltage Switch
procedure described below.

Since as per v3.00 spec, UHS-I supported hosts should set S18R
to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also
need to set XPC (bit 28) of OCR in case the host can supply >150mA.
This support is indicated by the Maximum Current Capabilities
register of the Host Controller.

If the response of ACMD41 has both CCS and S18A set, we start the
signal voltage switch procedure, which if successfull, will switch
the card from 3.3V signalling to 1.8V signalling. Signal voltage
switch procedure adds support for a new command CMD11 in the
Physical Layer Spec v3.01. As part of this procedure, we need to
set 1.8V Signalling Enable (bit 3) of Host Control2 register, which
if remains set after 5ms, means the switch to 1.8V signalling is
successfull. Otherwise, we clear bit 24 of OCR and retry the
initialization sequence. When we remove the card, and insert the
same or another card, we need to make sure that we start with 3.3V
signalling voltage. So we call mmc_set_signal_voltage() with
MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling
voltage before we actually start initializing the card.

Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.

Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: Ensure prototypes for SD API are visible in sd.c

So we know the implementation and prototypes agree with each other.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: Fix sd/sdio/mmc initialization frequency retries

Rewrite and clean up mmc_rescan() to properly retry frequencies lower
than 400kHz. Failures can happen both in sd_send_* calls and
mmc_attach_*. Break out "mmc_rescan_try_freq" from the frequency
selection loop. Symmetrize claim/release logic in mmc_attach_* API,
and move the sd_send_* calls there to make mmc_rescan easier to read.

Signed-off-by: Andy Ross <andy.ross@windriver.com>
Reviewed-and-Tested-by: Hein Tibosch <hein_tibosch@yahoo.es>
Reviewed-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: Add support for JMicron 388 SD/MMC controller

JMicron 388 SD/MMC combo controller supports the 1.8V low-voltage for
SD, but MMC doesn't work with the low-voltage, resulting in an error
at probing.

This patch adds the support for multiple voltage mask per device type,
so that SD works with 1.8V while MMC forces 3.3V. Here new ocr_avail_*
fields for each device are introduced, so that the actual OCR mask is
switched dynamically.

Also, the restriction of low-voltage in core/sd.c is removed when the
bit is allowed explicitly via ocr_avail_sd mask.

This patch was rewritten from scratch based on Aries' original code.

Signed-off-by: Aries Lee <arieslee@jmicron.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: propagate power save/restore ops return value

Allow power save/restore and their relevant mmc_bus_ops handlers
exit with a return value.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Tested-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: Add helper function to check if a card is removable

There are two checks that need to be made when determining whether a
card is removable. A host controller may set MMC_CAP_NONREMOVABLE if the
controller does not support removing cards (e.g. eMMC), in which case
the card is physically non-removable. Also the 'mmc_assume_removable'
module parameter can be configured at module load time, in which case
the card may be logically non-removable.

A helper function keeps the logic in one place so that code always
checks both conditions.

Because this new function is likely to be called from modules we now
need to export the mmc_assume_removable symbol.

Signed-off-by: Matt Fleming <matt@console-pimps.org>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: add erase, secure erase, trim and secure trim operations

SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.

SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.

"erase_size" is the minimum size, in bytes, of an erase operation. For
MMC, "erase_size" is the erase group size reported by the card. Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector. For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.

SD/MMC cards can erase an arbitrarily large area up to and
including the whole card. When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:

1. A single erase command will make all other I/O on the card
wait. This is not a problem if the whole card is being erased, but
erasing one partition will make I/O for another partition on the
same card wait for the duration of the erase - which could be a
several minutes.

2. To be able to inform the user of erase progress.

3. The erase timeout becomes too large to be very useful.
Because the erase timeout contains a margin which is multiplied by
the size of the erase area, the value can end up being several
minutes for large areas.

"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.

For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.

For SD, "preferred_erase_size" is the allocation unit size specified by
the card.

"preferred_erase_size" is in bytes.

Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mmc: split mmc_sd_init_card()

This series adds support for SD combo cards to MMC/SD driver stack.

SD combo consists of SD memory and SDIO parts in one package. Since the
parts have a separate SD command sets, after initialization, they can be
treated as independent cards on one bus.

Changes are divided into two patches. First is just moving initialization
code around so that SD memory part init can be called from SDIO init.
Second patch is a proper change enabling SD memory along SDIO. I tried to
move as much no-op changes to the first patch so that it's easier to
follow the required changes to initialization flow for SDIO cards.

This is based on Simplified SDIO spec v.2.00. The init sequence is
slightly modified to follow current SD memory init implementation.
Command sequences, assuming SD memory and SDIO indeed ignore unknown
commands, are the same as before for both parts.

This patch:

Prepare for SD-combo (IO+mem) support by splitting SD memory
card init and related functions.

Signed-off-by: Michal Miroslaw <mirq-linux@rere.qmqm.pl>
Cc: Adrian Hunter <adrian.hunter@nokia.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

mmc: add module parameter to set whether cards are assumed removable

Some people run general-purpose distribution kernels on netbooks with
a card that is physically non-removable or logically non-removable
(e.g. used for /home) and cannot be cleanly unmounted during suspend.
Add a module parameter to set whether cards are assumed removable or
non-removable, with the default set by CONFIG_MMC_UNSAFE_RESUME.

In general, it is not possible to tell whether a card present in an MMC
slot after resume is the same that was there before suspend. So there are
two possible behaviours, each of which will cause data loss in some cases:

CONFIG_MMC_UNSAFE_RESUME=n (default): Cards are assumed to be removed
during suspend. Any filesystem on them must be unmounted before suspend;
otherwise, buffered writes will be lost.

CONFIG_MMC_UNSAFE_RESUME=y: Cards are assumed to remain present during
suspend. They must not be swapped during suspend; otherwise, buffered
writes will be flushed to the wrong card.

Currently the choice is made at compile time and this allows that to be
overridden at module load time.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Wouter van Heyst <larstiq@larstiq.dyndns.org>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mmc: propagate error codes back from bus drivers' suspend/resume methods

Especially for SDIO drivers which may have special conditions/errors to
report, it is a good thing to relay the returned error code back to upper
layers.

This also allows for the rationalization of the resume path where code to
"remove" a no-longer-existing or replaced card was duplicated into the
MMC, SD and SDIO bus drivers.

In the SDIO case, if a function suspend method returns an error, then all
previously suspended functions are resumed and the error returned. An
exception is made for -ENOSYS which the core interprets as "we don't
support suspend so just kick the card out for suspend and return success".

When resuming SDIO cards, the core code only validates the manufacturer
and product IDs to make sure the same kind of card is still present before
invoking functions resume methods. It's the function driver's
responsibility to perform further tests to confirm that the actual same
card is present (same MAC address, etc.) and return an error otherwise.

Signed-off-by: Nicolas Pitre <nico@marvell.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mmc_spi: fail gracefully if host or card do not support the switch command

Some time ago, I have send a patch to the mmc_spi subsystem changing the
error codes. This was after a discussion with Pierre about using EINVAL
only for non-recoverable errors. This patch was accepted as

http://git.kernel.org/linus/fdd858db7113ca64132de390188d7ca00701013d

Unfortunately, several weeks later, I realized that this patch has opened
a little can of worms because there are SD cards on the market which

a) claim that they support the switch command
AND
b) refuse to execute this command if operating in SPI mode.

So, such a card would get unusuable in an embedded linux system in SPI
mode, because the init sequence terminates with an error.

This patch adds the missing error codes to the caller of the switch
command and restores the old behaviour to fail gracefully if these
commands can not execute.

Signed-off-by: Wolfgang Muees <wolfgang.mues@auerswald.de>
Cc: <linux-mmc@vger.kernel.org>
Cc: <stable@kernel.org> [2.6.31.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mmc: add ability to save power by powering off cards

Power can be saved by powering off cards that are not in use. This is
similar to suspend / resume except it is under the control of the driver,
and does not require any power management support. It can only be used
when the driver can monitor whether the card is removed, otherwise it is
unsafe. This is possible because, unlike suspend, the driver still
receives card detect and / or cover switch interrupts.

Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Matt Fleming <matt@console-pimps.org>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
Cc: Jarkko Lavinen <jarkko.lavinen@nokia.com>
Cc: Denis Karpov <ext-denis.2.karpov@nokia.com>
Cc: Pierre Ossman <pierre@ossman.eu>
Cc: Philip Langdale <philipl@overt.org>
Cc: "Madhusudhan" <madhu.cr@ti.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mmc: add MMC_CAP_NONREMOVABLE host capability

eMMC's are not removable, so unsafe resume is OK always.

To permit this a new host capability MMC_CAP_NONREMOVABLE has been added
and suspend / resume updated accordingly.

Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Matt Fleming <matt@console-pimps.org>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
Cc: Jarkko Lavinen <jarkko.lavinen@nokia.com>
Cc: Denis Karpov <ext-denis.2.karpov@nokia.com>
Cc: Pierre Ossman <pierre@ossman.eu>
Cc: Philip Langdale <philipl@overt.org>
Cc: "Madhusudhan" <madhu.cr@ti.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

driver model: constify attribute groups

Let attribute group vectors be declared "const". We'd
like to let most attribute metadata live in read-only
sections... this is a start.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

mmc_spi: do not check CID and CSD blocks with CRC16

Some cards are not able to calculate a valid CRC16 value
for CID and CSD reads (CRC for 512 byte data blocks is OK).
By moving the CRC enable after the read of CID and CSD, these
cards can be used. This patch was tested with a faulty 8 GByte
takeMS Class 6 SDHC card. This patch was suggested by
Pierre Ossman.

Signed-off-by: Wolfgang Muees <wolfgang.mues@auerswald.de>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>

MMC: Trivial comment cleanup

Make the variable name in the comments match the actual name
of the variable.

Signed-off-by: Deepak Saxena <dsaxena@laptop.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: change .get_ro() callback semantics

Now get_ro() callback must return 0/1 values for its logical states, and
negative errno values in case of error. If particular host instance doesn't
support RO/WP switch, it should return -ENOSYS.

This patch changes some hosts in two ways:

1. Now functions should be smart to not return negative values in
"RO asserted" case (particularly gpio_ calls could return negative
values for the outermost GPIOs).

Also, board code usually passes get_ro() callbacks that directly return
gpioreg & bit result, so at91_mci, imxmmc, pxamci and mmc_spi's get_ro()
handlers need take special care when returning platform's values to the
mmc core.

2. In case of host instance didn't implement get_ro() callback, it should
really return -ENOSYS and let the mmc core decide what to do about it
(mmc core thinks the same way as the hosts, so it isn't functional
change).

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: use sysfs groups to handle conditional attributes

Suppressing uevents turned out to be a bad idea as it screws up the
order of events, making user space very confused. Change the system to
use sysfs groups instead.

This is a regression that, for some odd reason, has gone unnoticed for
some time. It confuses hal so that the block devices (which have the
mmc device as a parent) are not registered. End result being that
desktop magic when cards are inserted won't work.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

MMC core learns about SPI

Teach the MMC/SD/SDIO core about using SPI mode.

- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.

- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.

- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.

- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue

Those changes required some new and updated primitives:

- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode

- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.

- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper

- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI

The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: replace BUG_ON with WARN_ON

Replace all cases of BUG_ON with WARN_ON where there is a chance
(with varying degrees of slim) that the kernel can continue without
incidence.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: improve error code feedback

Now that we use "normal" error codes, improve the reporting and response
to error codes in the core.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: remove custom error codes

Convert the MMC layer to use standard error codes and not its own,
incompatible values.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: add missing printk levels

Some printk:s were missing an explicit level.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: be more verbose about card insertions/removal

Let the user know that the kernel actually detected the card
by printing some basic information in dmesg.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: Don't hold lock when releasing an added card

When the card has been added to the device model, it might be bound
to a card driver. Therefore, we have to release the host lock when
trying to remove it as we otherwise might deadlock with the driver.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: update header file paths

Make sure all headers in the files reflect their true position
in the tree.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: refactor bus operations

Move bus operations to its own file for the sake of clarity. Also
delegate sysfs attributes to bus handlers in preparation for other
more exotic types.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: get back read-only switch function

Somehow the code to read the read-only switch of SD cards got lost
in the reorganisation.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: don't call switch on old cards

Make sure we don't call the switch function on cards too old to
support it. They should just ignore it, but some have been reported
to lock up instead.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: fix broken if clause

Fix a broken if clause which was causing SD cards to go into
4-bit mode even if the host did not support it.

(Reported by David Brownell and Marc Pignat)

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: remove old card states

Remove card states that no longer make any sense.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: support unsafe resume of cards

Since many have the system root on MMC/SD we must allow some foot
shooting when it comes to resume.

We cannot detect if a card is removed and reinserted during suspend,
so the safe approach would be to assume it was, avoiding potential
filesystem corruption. This will of course not work if you cannot
release the card before suspend.

This commit adds a compile time option that makes the MMC layer
assume the card wasn't touched if it is redetected upon resume.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: break apart switch function

Break apart the SD switch function into one that reads the capabilities
and one that acts on them.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

MMC: Fix handling of low-voltage cards

Fix handling of low voltage MMC cards.

The latest MMC and SD specs both agree that support for
low-voltage operations is indicated by bit 7 in the OCR.
The MMC spec states that the low voltage range is
1.65-1.95V while the SD spec leaves the actual voltage
range undefined - meaning that there is still no such
thing as a low voltage SD card.

However, an old Sandisk spec implied that bits 7.0
represented voltages below 2.0V in 1V or 0.5V increments,
and the code was accordingly written with that expectation.

This confusion meant that host drivers attempting to support
the typical low voltage (1.8V) would set the wrong bits in
the host OCR mask (usually bits 5 and/or 6) resulting in the
the low voltage mode never being used.

This change corrects the low voltage range and adds sanity
checks on the reserved bits (0-6) and for SD cards that
claim to support low-voltage operations.

Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

mmc: add bus handler

Delegate protocol handling to "bus handlers". This allows the core to
just handle the task of arbitrating the bus. Initialisation and
pampering of cards is now done by the different bus handlers.

This design also allows MMC and SD (and later SDIO) to be more cleanly
separated, allowing easier maintenance.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>