linux/drivers/mmc/core, branch v2.6.32

mmc: sdio: don't require CISTPL_VERS_1 to contain 4 strings

2009-10-08T14:36:40Z

The PC Card 8.0 specification (vol. 4, section 3.2.10) says the TPLLV1_INFO field of the CISTPL_VERS_1 tuple must contain 4 strings. Some cards don't have all 4 so just parse as many as we can. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: David Vrabel Tested-by: Jonathan Cameron Tested-by: Bing Zhao Cc: Roel Kluin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

sdio: pass whitelisted cis funce tuples to sdio drivers

2009-10-01T23:11:12Z

Some manufacturers provide vendor information in non-vendor specific CIS tuples. For example, Broadcom uses an Extended Function tuple to provide the MAC address on some of their network cards, as in the case of the Nintendo Wii WLAN daughter card. This patch allows passing whitelisted FUNCE tuples unknown to the SDIO core to a matching SDIO driver instead of rejecting them and failing. Signed-off-by: Albert Herranz Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

const: constify remaining file_operations

2009-10-01T23:11:11Z

[akpm@linux-foundation.org: fix KVM] Signed-off-by: Alexey Dobriyan Acked-by: Mike Frysinger Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mmc: make SDIO device/driver struct accessors public

2009-09-23T14:39:38Z

Especially with the PM framework, those are quite handy to have in driver code too. Signed-off-by: Nicolas Pitre Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

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

2009-09-23T14:39:38Z

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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mmc: core SDIO suspend/resume support

2009-09-23T14:39:38Z

Currently, all SDIO cards are virtually removed upon a suspend, and completely reprobed upon a resume. This adds the suspend and resume methods to the SDIO bus driver so to be able to dispatch those events to the actual SDIO function drivers for real suspend/resume instead. All active functions on a card must have a driver with both a suspend and a resume method though. Failing that, we fall back to the current behavior of simply "removing" the card when suspending. When resuming, we make sure the same card is still inserted by comparing the vendor and product IDs. If there is a mismatch, or if there is simply no card anymore in the slot, then the previous card is "removed" and the new card is detected. This is further enhanced with the next patch. [akpm@linux-foundation.org: fix warnings] Signed-off-by: Nicolas Pitre Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

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

2009-09-23T14:39:37Z

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 Cc: Cc: [2.6.31.x] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

sdio: add MMC_QUIRK_LENIENT_FN0

2009-09-23T14:39:37Z

Normally writes to SDIO function 0 outside the vendor specific CCCR registers are prohibited. To support embedded devices that require writes to SDIO function 0 outside this range (e.g. TI WL127x embedded sdio wifi device), MMC_QUIRK_LENIENT_FN0 is introduced. A card quirks field is added to `struct mmc_card' to support non-standard devices (e.g. embedded sdio devices). [akpm@linux-foundation.org: code in C, not cpp!] Signed-off-by: Ohad Ben-Cohen Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

sdio: fix read buffer overflow

2009-09-23T14:39:36Z

Avoid buffer underrun when parsing an invalid CISTPL_VERS_1. Signed-off-by: Roel Kluin Cc: David Vrabel Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

sdio: add CD disable support

2009-09-23T14:39:36Z

Add support to disconnect the pull-up resistor on CD/DAT[3] (pin 1) of the card. This may be desired on certain setups of boards, controllers and embedded sdio devices which do not need the card's pull-up. As a result, card detection is disabled and power is saved. [akpm@linux-foundation.org: simplify sdio_disable_cd() a bit] Signed-off-by: Ohad Ben-Cohen Acked-by: Matt Fleming Cc: Ian Molton Cc: "Roberto A. Foglietta" Cc: Philip Langdale Cc: Pierre Ossman Cc: David Vrabel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds