Embed UHS-II access/control functionality into the MMC request
processing flow.
Signed-off-by: Jason Lai <jason.lai@genesyslogic.com.tw>
Signed-off-by: Victor Shih <victor.shih@genesyslogic.com.tw>
Message-ID: <20241018105333.4569-2-victorshihgli@gmail.com>
[Ulf: A couple of cleanups and fixed sd_uhs2_power_off()]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
SDUC memory addressing spans beyond 2TB and up to 128TB. Therefore, 38
bits are required to access the entire memory space of all sectors.
Those extra 6 bits are to be carried by CMD22 prior of sending
read/write/erase commands: CMD17, CMD18, CMD24, CMD25, CMD32, and CMD33.
CMD22 will carry the higher order 6 bits, and must precedes any of the
above commands even if it targets sector < 2TB.
No error related to address or length is indicated in CMD22 but rather
in the read/write command itself.
Tested-by: Ricky WU <ricky_wu@realtek.com>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Link: https://lore.kernel.org/r/20241006051148.160278-3-avri.altman@wdc.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Replace with already defined values for readability. While at it, let's
also change the mode-parameter from an int to bool, as the only used values
are 0 or 1.
Signed-off-by: Chanwoo Lee <cw9316.lee@samsung.com>
Link: https://lore.kernel.org/r/20240829024709.402285-1-cw9316.lee@samsung.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Extensive testing has shown that some specific SD cards require an
increased command timeout to be successfully initialized.
More info:
Platform: Rockchip SoC + DW Multimedia host Controller
SD card: Xvv microSD CMH34A17TMA12 (Made in Korea)
Note: The SD card is custom-made by the customer in collaboration
with the wafer foundry.
Signed-off-by: Felix Qin <xiaokeqinhealth@126.com>
Acked-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20240429071955.163282-1-xiaokeqinhealth@126.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Similar to what has already been changed for eMMC and the MMC_SEND_OP_COND
(CMD1), let's convert the SD_APP_OP_COND (ACMD41) for SD cards to use the
common __mmc_poll_for_busy() too.
This change means the initial delay period, that starts as 10ms will now
increase for every loop when being busy. The total accepted timeout for
being busy is 1s, which is according to the SD spec.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Felix Qin <xiaokeqinhealth@126.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20240425133034.79599-1-ulf.hansson@linaro.org
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>
The SD_SWITCH (CMD6) is an ADTC type of command with an R1 response, which
can be sent by using the mmc_send_adtc_data(). Let's do that and drop the
open coding in mmc_sd_switch().
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-8-ulf.hansson@linaro.org
In the SD specification v7.10 the SD express card has been added. This new
type of removable SD card, can be managed via a PCIe/NVMe based interface,
while also allowing backwards compatibility towards the legacy SD
interface.
To keep the backwards compatibility, it's required to start the
initialization through the legacy SD interface. If it turns out that the
mmc host and the SD card, both supports the PCIe/NVMe interface, then a
switch should be allowed.
Therefore, let's introduce some basic support for this type of SD cards to
the mmc core. The mmc host, should set MMC_CAP2_SD_EXP if it supports this
interface and MMC_CAP2_SD_EXP_1_2V, if also 1.2V is supported, as to inform
the core about it.
To deal with the switch to the PCIe/NVMe interface, the mmc host is
required to implement a new host ops, ->init_sd_express(). Based on the
initial communication between the host and the card, host->ios.timing is
set to either MMC_TIMING_SD_EXP or MMC_TIMING_SD_EXP_1_2V, depending on if
1.2V is supported or not. In this way, the mmc host can check these values
in its ->init_sd_express() ops, to know how to proceed with the handover.
Note that, to manage card insert/removal, the mmc core sticks with using
the ->get_cd() callback, which means it's the host's responsibility to make
sure it provides valid data, even if the card may be managed by PCIe/NVMe
at the moment. As long as the card seems to be present, the mmc core keeps
the card powered on.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Rui Feng <rui_feng@realsil.com.cn>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1603936636-3126-1-git-send-email-rui_feng@realsil.com.cn
Based on 1 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 as published by
the free software foundation either version 2 of the license or at
your option any later version
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All callers of mmc_wait_for_app_cmd() set the retries in-parameter to
MMC_CMD_RETRIES. This is silly, so let's just drop the in-parameter
altogether, as to simplify the code.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc_wait_for_app_cmd() is an internal function for sd_ops.c, thus let's
drop the unnecessary export and turn it into static function.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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>
In the MMC subsystem, we see such initializers that only clears the
first member explicitly.
For example,
struct mmc_request mrq = {NULL};
sets the first member (.sbc) to NULL explicitly. However, this is
an unstable form because we may insert a non-pointer member at the
top of the struct mmc_request in the future. (if we do so, the
compiler will spit warnings.)
So, using a designated initializer is preferred coding style. The
expression above is equivalent to:
struct mmc_request mrq = { .sbc = NULL };
Of course, this does not express our intention. We want to fill
all struct members with zeros. Please note struct members are
implicitly zero-cleared unless otherwise specified in the initializer.
After all, the most reasonable (and stable) form is:
struct mmc_request mrq = {};
Do likewise for mmc_command, mmc_data as well.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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>
Variable assignment just before return is redundant.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The initialization of some SD-cards fails because the card never
leaves the busy state. Aid trouble shooting by indicating this in the
kernel log.
Signed-off-by: Johan Rudholm <johanru@axis.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
These two basic defines were everywhere, simply because module.h
was also everywhere. But we are cleaning up the latter. So make
the exporters actually call out their need for the include.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Fix the sparse warning output "warning: Using plain integer as NULL pointer"
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Allows appropriately-privileged applications to send CMD (normal) and ACMD
(application-specific; preceded with CMD55) commands to cards/devices on
the mmc bus. This is primarily useful for enabling the security
functionality built in to every SD card.
It can also be used as a generic passthrough (e.g. to enable virtual
machines to control mmc bus devices directly). However, this use case has
not been tested rigorously. Generic passthrough testing was only conducted
for a few non-security opcodes to prove the feasibility of the passthrough.
Since any opcode can be sent using this passthrough, it is very possible to
render the card/device unusable. Applications that use this ioctl must
have CAP_SYS_RAWIO.
Security commands tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652 SoC,
TI OMAP3621/OMAP3630 SoC, Samsung S5PC110 SoC, Qualcomm MSM7200A SoC.
Signed-off-by: John Calixto <john.calixto@modsystems.com>
Reviewed-by: Andrei Warkentin <andreiw@motorola.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Converts from:
struct mmc_request mrq;
memset(&mrq, 0, sizeof(struct mmc_request));
to:
struct mmc_request mrq = {0};
because it's shorter, as performant, and easier to work out whether
initialization has happened.
Signed-off-by: Chris Ball <cjb@laptop.org>
Converts from:
struct mmc_data data;
memset(&data, 0, sizeof(struct mmc_data));
to:
struct mmc_data data = {0};
because it's shorter, as performant, and easier to work out whether
initialization has happened.
Signed-off-by: Chris Ball <cjb@laptop.org>
Converts from:
struct mmc_command cmd;
memset(&cmd, 0, sizeof(struct mmc_command));
to:
struct mmc_command cmd = {0};
because it's shorter, as performant, and easier to work out whether
initialization has happened.
Signed-off-by: Chris Ball <cjb@laptop.org>
mmc_cmd_app did not zero out mmc_command on stack.
Reported-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
This patch is based on the commit "af51715079e7fb6b290e1881d63d815dc4de5011":
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
The driver may invalidate the mmc_card->csd when host driver uses dma.
So this subroutine also needs a kmalloc buffer.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
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>
The clearing of mrq via a memset at the top of the for loop in
mmc_wait_for_app_cmd() is not required as mrq is not used and there is
another clearing of mrq just below. We remove the first memset since if
the initial tests in the for loop fail the memset is not required.
Signed-off-by: Mark Asselstine <asselsm@gmail.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>
Not architecture specific code should not #include <asm/scatterlist.h>.
This patch therefore either replaces them with
#include <linux/scatterlist.h> or simply removes them if they were
unused.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
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>
The write parameter in mmc_set_data_timeout() is redundant as the
data structure contains information about the direction of the
transfer.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
This patch makes the following needlessly global functions static:
- sd_ops.c: mmc_app_cmd()
- core.c: __mmc_release_bus()
- core.c: mmc_start_request()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Move protocol operations and definitions into their own files
in an effort to separate protocol handling and bus
arbitration more clearly.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
