user/sven/linux.git/drivers/mmc/core, branch v3.4.7

mmc: cd-gpio: protect against NULL context in mmc_cd_gpio_free()

2012-06-01T07:18:27Z

commit 0e9f480bb553d39ee06ccd45639ba7a5446a7b81 upstream. Do not oops, even if mmc_cd_gpio_free() is mistakenly called on a driver cleanup path, even though a previous call to mmc_cd_gpio_request() failed. Signed-off-by: Guennadi Liakhovetski [stable@: please apply to 3.3-stable] Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: sdio: avoid spurious calls to interrupt handlers

2012-06-01T07:18:26Z

commit bbbc4c4d8c5face097d695f9bf3a39647ba6b7e7 upstream. Commit 06e8935feb ("optimized SDIO IRQ handling for single irq") introduced some spurious calls to SDIO function interrupt handlers, such as when the SDIO IRQ thread is started, or the safety check performed upon a system resume. Let's add a flag to perform the optimization only when a real interrupt is signaled by the host driver and we know there is no point confirming it. Reported-by: Sujit Reddy Thumma Signed-off-by: Nicolas Pitre Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: core: Do not pre-claim host in suspend

2012-04-21T01:52:13Z

Since SDIO drivers may want to do some SDIO operations in their suspend callback functions, we must not keep the host claimed when calling them. Daniel Drake reported that libertas_sdio encountered a deadlock in its suspend function. Signed-off-by: Ulf Hansson Tested-by: Daniel Drake [stable@: please apply to 3.2-stable and 3.3-stable] Cc: stable Signed-off-by: Chris Ball

mmc: cd-gpio: Include header to pickup exported symbol prototypes

2012-04-21T00:45:00Z

Include the linux/mmc/cd-gpio.h header to pickup the prototypes for the two exported symbols. This quiets the sparse warnings: warning: symbol 'mmc_cd_gpio_request' was not declared. Should it be static? warning: symbol 'mmc_cd_gpio_free' was not declared. Should it be static? Signed-off-by: H Hartley Sweeten Acked-by: Guennadi Liakhovetski Acked-by: Venkatraman S Signed-off-by: Chris Ball

mmc: remove MMC bus legacy suspend/resume method

2012-04-21T00:30:19Z

MMC bus is using legacy suspend/resume method, which is not compatible if runtime pm callbacks are used. In this scenario, MMC bus suspend/resume callbacks cannot be called when system entering S3. So change to use the new defined dev_pm_ops for system sleeping mode. Tested on AM335x Platform. Solves major issue/crash reported at http://www.mail-archive.com/linux-omap@vger.kernel.org/msg65425.html Signed-off-by: Chuanxiao Dong Tested-by: Hebbar, Gururaja Acked-by: Linus Walleij Acked-by: Ulf Hansson Signed-off-by: Chris Ball

mmc: fixes for eMMC v4.5 sanitize operation

2012-04-21T00:28:58Z

eMMC v4.5 sanitize operation erases all copies of unmapped data. However trim or erase operations must be used first to unmap the required sectors. That was not being done. Fixes apply to linux 3.2 on. Signed-off-by: Adrian Hunter Cc: Acked-by: Jaehoon Chung Acked-by: Linus Walleij Signed-off-by: Chris Ball

mmc: fixes for eMMC v4.5 discard operation

2012-04-21T00:28:55Z

eMMC v4.5 discard operation is significantly different from the existing trim operation because it is not guaranteed to work with the new sanitize operation. Consequently mmc_can_trim() is separated from mmc_can_discard(). Also the new discard operation does not result in the sectors being set to all-zeros, so discard_zeroes_data must not be set. In addition, the new discard has the same timeout as trim, but from v4.5 trim is defined to use the hc timeout. The timeout calculation is adjusted accordingly. Fixes apply to linux 3.2 on. Signed-off-by: Adrian Hunter Cc: Acked-by: Jaehoon Chung Acked-by: Linus Walleij Signed-off-by: Chris Ball

mmc: use really long write timeout to deal with crappy cards

2012-04-06T00:32:34Z

Several people have noticed that crappy SD cards take much longer to complete multiple block writes than the 300ms that Linux specifies. Try to work around this by using a three second write timeout instead. This is a generalized version of a patch from Chase Maupin , whose patch description said: * With certain SD cards timeouts like the following have been seen due to an improper calculation of the dto value: mmcblk0: error -110 transferring data, sector 4126233, nr 8, card status 0xc00 * By removing the dto calculation and setting the timeout value to the maximum specified by the SD card specification part A2 section 2.2.15 these timeouts can be avoided. * This change has been used by beagleboard users as well as the Texas Instruments SDK without a negative impact. * There are multiple discussion threads about this but the most relevant ones are: * http://talk.maemo.org/showthread.php?p=1000707#post1000707 * http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42213.html * Original proposal for this fix was done by Sukumar Ghoral of Texas Instruments * Tested using a Texas Instruments AM335x EVM Signed-off-by: Paul Walmsley Tested-by: Tony Lindgren Signed-off-by: Chris Ball

mmc: core: fix power class selection

2012-04-06T00:32:31Z

mmc_select_powerclass() function returns error if eMMC VDD level supported by host is between 2.7v to 3.2v. According to eMMC specification, valid voltage for high voltage cards is 2.7v to 3.6v. This patch ensures that 2.7v to 3.6v VDD range is treated as valid range. Also, failure to set the power class shouldn't be treated as fatal error because even if setting the power class fails, card can still work in default power class. If mmc_select_powerclass() returns error, just print the warning message and go ahead with rest of the card initialization. Signed-off-by: Subhash Jadavani Acked-by: Girish K S Reviewed-by: Namjae Jeon Signed-off-by: Chris Ball

mmc: sdio: Use empty system suspend/resume callbacks at the bus level

2012-04-06T00:32:26Z

Neil Brown reports that commit 35cd133c PM: Run the driver callback directly if the subsystem one is not there breaks suspend for his libertas wifi, because SDIO has a protocol where the suspend method can return -ENOSYS and this means "There is no point in suspending, just turn me off". Moreover, the suspend methods provided by SDIO drivers are not supposed to be called by the PM core or bus-level suspend routines (which aren't presend for SDIO). Instead, when the SDIO core gets to suspend the device's ancestor, it calls the device driver's suspend function, catches the ENOSYS, and turns the device off. The commit above breaks the SDIO core's assumption that the device drivers' callbacks won't be executed if it doesn't provide any bus-level callbacks. If fact, however, this assumption has never been really satisfied, because device class or device type suspend might very well use the driver's callback even without that commit. The simplest way to address this problem is to make the SDIO core tell the PM core to ignore driver callbacks, for example by providing no-operation suspend/resume callbacks at the bus level for it, which is implemented by this change. Reported-and-tested-by: Neil Brown Signed-off-by: Rafael J. Wysocki [stable: please apply to 3.3-stable only] Cc: Signed-off-by: Chris Ball