summaryrefslogtreecommitdiff
path: root/drivers/mmc/core/sd_ops.c
AgeCommit message (Collapse)Author
2011-10-31mmc: Add export.h for EXPORT_SYMBOL/THIS_MODULE as requiredPaul Gortmaker
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>
2011-10-26mmc: fix integer assignments to pointerVenkatraman S
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>
2011-05-24mmc: core: Add mmc CMD+ACMD passthrough ioctlJohn Calixto
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>
2011-05-24mmc: initialize struct mmc_request at declaration timeChris Ball
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>
2011-05-24mmc: initialize struct mmc_data at declaration timeChris Ball
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>
2011-05-24mmc: initialize struct mmc_command at declaration timeChris Ball
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>
2011-05-24mmc: core: Fix use of uninitialized data in mmc_send_if_cond.Chris Ball
mmc_send_if_cond did not zero out mmc_command on stack. Signed-off-by: Chris Ball <cjb@laptop.org>
2011-05-24mmc: core: Fix use of uninitialized data in mmc_cmd_app.Andrei Warkentin
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>
2011-03-25mmc: fix mmc_app_send_scr() for dma transferYoshihiro Shimoda
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>
2010-08-12mmc: add erase, secure erase, trim and secure trim operationsAdrian Hunter
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>
2010-05-27mmc: sd: clean up redundant memsetMark Asselstine
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>
2007-11-02cleanup asm/scatterlist.h includesAdrian Bunk
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>
2007-10-27mmc: use common byte swap macrosPierre Ossman
Use the more generic byte swapping macros instead of the socket variants. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-09-23MMC core learns about SPIDavid Brownell
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>
2007-09-23mmc: mmc_set_data_timeout() parameter write is redundantPierre Ossman
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>
2007-09-23mmc: remove custom error codesPierre Ossman
Convert the MMC layer to use standard error codes and not its own, incompatible values. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-07-26drivers/mmc/core/: make 3 functions staticAdrian Bunk
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>
2007-07-26mmc: update kerneldocPierre Ossman
Make sure the kerneldoc comments are up to date and relevant. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-07-26mmc: update header file pathsPierre Ossman
Make sure all headers in the files reflect their true position in the tree. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-05-01mmc: Separate out protocol opsPierre Ossman
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>