History log of /drivers/mmc/core/sd_ops.c
Revision Date Author Comments
5e863662add1fc00bf088dc381b787edc0a0de5b 23-May-2014 Johan Rudholm <johan.rudholm@axis.com> mmc: sd: warn if card stays busy during init

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>
3ef77af154b03776c6c662c68c6332719e9eecac 10-Jul-2011 Paul Gortmaker <paul.gortmaker@windriver.com> mmc: Add export.h for EXPORT_SYMBOL/THIS_MODULE as required

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>
ad5fd97288655b5628052c1fa906419417c86100 24-Aug-2011 Venkatraman S <svenkatr@ti.com> mmc: fix integer assignments to pointer

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>
cb87ea28ed9e75a41eb456bfcb547b4e6f10e750 27-Apr-2011 John Calixto <john.calixto@modsystems.com> mmc: core: Add mmc CMD+ACMD passthrough ioctl

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>
24f5b53ba076e983bc64fa48534ca795d7813d51 14-Apr-2011 Chris Ball <cjb@laptop.org> mmc: initialize struct mmc_request at declaration time

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>
a61ad2b49bfce94dfddce828cd9222e4b9e7825b 14-Apr-2011 Chris Ball <cjb@laptop.org> mmc: initialize struct mmc_data at declaration time

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>
1278dba167f01bb3c6626d16450d31129d041087 14-Apr-2011 Chris Ball <cjb@laptop.org> mmc: initialize struct mmc_command at declaration time

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>
30574ed143e10dd19295b7d80be55f2cd6764c6f 13-Apr-2011 Chris Ball <cjb@laptop.org> mmc: core: Fix use of uninitialized data in mmc_send_if_cond.

mmc_send_if_cond did not zero out mmc_command on stack.

Signed-off-by: Chris Ball <cjb@laptop.org>
87f6119e25bbe0fd60e76f599d5fa10cf489519c 13-Apr-2011 Andrei Warkentin <andreiw@motorola.com> mmc: core: Fix use of uninitialized data in mmc_cmd_app.

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>
4f665cb614b8a258b507cc47753dd3f7dd45aac6 25-Mar-2011 Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> mmc: fix mmc_app_send_scr() for dma transfer

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>
dfe86cba7676d58db8de7e623f5e72f1b0d3ca35 11-Aug-2010 Adrian Hunter <adrian.hunter@nokia.com> 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>
6dd6bca3fb6d4f186cdc67ba9e3949ef456dcc53 26-May-2010 Mark Asselstine <asselsm@gmail.com> mmc: sd: clean up redundant memset

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>
87ae9afdcada236d0a1b38ce2c465a65916961dc 30-Oct-2007 Adrian Bunk <bunk@kernel.org> cleanup asm/scatterlist.h includes

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>
1fa8dd146f6bf57902602522c212040f8fa6fcd3 27-Oct-2007 Pierre Ossman <drzeus@drzeus.cx> mmc: use common byte swap macros

Use the more generic byte swapping macros instead of the socket variants.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
af51715079e7fb6b290e1881d63d815dc4de5011 08-Aug-2007 David Brownell <david-b@pacbell.net> 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>
b146d26a61e0feab2f12a98ae83fd352830899c0 24-Jul-2007 Pierre Ossman <drzeus@drzeus.cx> mmc: mmc_set_data_timeout() parameter write is redundant

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>
17b0429dde9ab60f9cee8e07ab28c7dc6cfe6efd 22-Jul-2007 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>
393618510d5349e07d71dc28fb6fc49baf0d96a0 25-Jul-2007 Adrian Bunk <bunk@stusta.de> drivers/mmc/core/: make 3 functions static

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>
67a61c484735de9bf4f099830ecb4ef2eca95c38 11-Jul-2007 Pierre Ossman <drzeus@drzeus.cx> mmc: update kerneldoc

Make sure the kerneldoc comments are up to date and relevant.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
70f10482c668301c483acded13bf68780ad352b9 11-Jul-2007 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>
da7fbe58d2d347e95af699ddf04d885be6362bbe 24-Dec-2006 Pierre Ossman <drzeus@drzeus.cx> mmc: Separate out protocol ops

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>