<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/mmc/core, branch v3.4.83</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/mmc/core?h=v3.4.83</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/mmc/core?h=v3.4.83'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-05-08T02:51:57Z</updated>
<entry>
<title>mmc: core: Fix bit width test failing on old eMMC cards</title>
<updated>2013-05-08T02:51:57Z</updated>
<author>
<name>Philip Rakity</name>
<email>prakity@yahoo.com</email>
</author>
<published>2013-04-04T19:18:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=217fd3afce27de54b0b10fc33ce6268c999dbdb4'/>
<id>urn:sha1:217fd3afce27de54b0b10fc33ce6268c999dbdb4</id>
<content type='text'>
commit 836dc2fe89c968c10cada87e0dfae6626f8f9da3 upstream.

PARTITION_SUPPORT needs to be set before doing the compare on version
number so the bit width test does not get invalid data.  Before this
patch, a Sandisk iNAND eMMC card would detect 1-bit width although
the hardware supports 4-bit.

Only affects old emmc devices - pre 4.4 devices.

Reported-by: Elad Yi &lt;elad.yi@gmail.com&gt;
Signed-off-by: Philip Rakity &lt;prakity@yahoo.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: cd-gpio: protect against NULL context in mmc_cd_gpio_free()</title>
<updated>2012-06-01T07:18:27Z</updated>
<author>
<name>Guennadi Liakhovetski</name>
<email>g.liakhovetski@gmx.de</email>
</author>
<published>2012-04-24T15:56:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6cd4efb3a17356075c8e3f1bd191b4d120714851'/>
<id>urn:sha1:6cd4efb3a17356075c8e3f1bd191b4d120714851</id>
<content type='text'>
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 &lt;g.liakhovetski@gmx.de&gt;
[stable@: please apply to 3.3-stable]
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdio: avoid spurious calls to interrupt handlers</title>
<updated>2012-06-01T07:18:26Z</updated>
<author>
<name>Nicolas Pitre</name>
<email>nicolas.pitre@linaro.org</email>
</author>
<published>2012-04-16T23:16:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=11c8c735ebf68c754bdd94cebd307a96fcd95068'/>
<id>urn:sha1:11c8c735ebf68c754bdd94cebd307a96fcd95068</id>
<content type='text'>
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 &lt;sthumma@codeaurora.org&gt;
Signed-off-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: core: Do not pre-claim host in suspend</title>
<updated>2012-04-21T01:52:13Z</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@stericsson.com</email>
</author>
<published>2012-04-19T09:55:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7c5709194096beea1ab6e6db46768d70a068efb0'/>
<id>urn:sha1:7c5709194096beea1ab6e6db46768d70a068efb0</id>
<content type='text'>
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 &lt;ulf.hansson@stericsson.com&gt;
Tested-by: Daniel Drake &lt;dsd@laptop.org&gt;
[stable@: please apply to 3.2-stable and 3.3-stable]
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: cd-gpio: Include header to pickup exported symbol prototypes</title>
<updated>2012-04-21T00:45:00Z</updated>
<author>
<name>H Hartley Sweeten</name>
<email>hartleys@visionengravers.com</email>
</author>
<published>2012-04-17T20:03:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5ca6518832ac913ac277b50ceddda8372dbf7bea'/>
<id>urn:sha1:5ca6518832ac913ac277b50ceddda8372dbf7bea</id>
<content type='text'>
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 &lt;hsweeten@visionengravers.com&gt;
Acked-by: Guennadi Liakhovetski &lt;g.liakhovetski@gmx.de&gt;
Acked-by: Venkatraman S &lt;svenkatr@ti.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: remove MMC bus legacy suspend/resume method</title>
<updated>2012-04-21T00:30:19Z</updated>
<author>
<name>Chuanxiao Dong</name>
<email>chuanxiao.dong@intel.com</email>
</author>
<published>2012-04-11T11:54:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=32d317c60e56c2a34463b51fc0336cc96b3e1735'/>
<id>urn:sha1:32d317c60e56c2a34463b51fc0336cc96b3e1735</id>
<content type='text'>
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 &lt;chuanxiao.dong@intel.com&gt;
Tested-by: Hebbar, Gururaja &lt;gururaja.hebbar@ti.com&gt;
Acked-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@stericsson.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: fixes for eMMC v4.5 sanitize operation</title>
<updated>2012-04-21T00:28:58Z</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2012-04-05T11:45:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=283028122db37621b124f079ca8eae5b64807ad4'/>
<id>urn:sha1:283028122db37621b124f079ca8eae5b64807ad4</id>
<content type='text'>
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 &lt;adrian.hunter@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Acked-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: fixes for eMMC v4.5 discard operation</title>
<updated>2012-04-21T00:28:55Z</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2012-04-05T11:45:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7194efb8f063ee3aa0cb50d9002348887e68ec10'/>
<id>urn:sha1:7194efb8f063ee3aa0cb50d9002348887e68ec10</id>
<content type='text'>
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 &lt;adrian.hunter@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Acked-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: use really long write timeout to deal with crappy cards</title>
<updated>2012-04-06T00:32:34Z</updated>
<author>
<name>Paul Walmsley</name>
<email>paul@pwsan.com</email>
</author>
<published>2012-03-12T10:58:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3bdc9ba892d6a294d16e9e6e0c4041926aa3d58c'/>
<id>urn:sha1:3bdc9ba892d6a294d16e9e6e0c4041926aa3d58c</id>
<content type='text'>
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
&lt;Chase.Maupin@ti.com&gt;, 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 &lt;paul@pwsan.com&gt;
Tested-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: fix power class selection</title>
<updated>2012-04-06T00:32:31Z</updated>
<author>
<name>Subhash Jadavani</name>
<email>subhashj@codeaurora.org</email>
</author>
<published>2012-04-03T06:55:58Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=93fc5a47f25c41125b30c0bf4f243bf3204a1a0a'/>
<id>urn:sha1:93fc5a47f25c41125b30c0bf4f243bf3204a1a0a</id>
<content type='text'>
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 &lt;subhashj@codeaurora.org&gt;
Acked-by: Girish K S &lt;girish.shivananjappa@linaro.org&gt;
Reviewed-by: Namjae Jeon &lt;linkinjeon@gmail.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
</feed>
