<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/mmc, branch linux-5.16.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.16.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.16.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2022-04-13T18:03:19+00:00</updated>
<entry>
<title>mmc: core: Fixup support for writeback-cache for eMMC and SD</title>
<updated>2022-04-13T18:03:19+00:00</updated>
<author>
<name>Michael Wu</name>
<email>michael@allwinnertech.com</email>
</author>
<published>2022-03-31T07:32:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=902b2b297a2e7c1756d5c25b82f3cb7018a64217'/>
<id>urn:sha1:902b2b297a2e7c1756d5c25b82f3cb7018a64217</id>
<content type='text'>
commit 08ebf903af57cda6d773f3dd1671b64f73b432b8 upstream.

During the card initialization process, the mmc core checks whether the
eMMC/SD card supports an internal writeback-cache and then enables it
inside the card.

Unfortunately, this isn't according to what the mmc core reports to the
upper block layer. Instead, the writeback-cache support with REQ_FLUSH and
REQ_FUA, are being enabled depending on whether the host supports the CMD23
(MMC_CAP_CMD23) and whether an eMMC supports the reliable-write command.

This is wrong and it may also sound awkward. In fact, it's a remnant
from when both eMMC/SD cards didn't have dedicated commands/support to
control the internal writeback-cache. In other words, it was the best we
could do at that point in time.

To fix the problem, but also without breaking backwards compatibility,
let's align the REQ_FLUSH support with whether the writeback-cache became
successfully enabled - for both eMMC and SD cards.

Cc: stable@kernel.org
Fixes: 881d1c25f765 ("mmc: core: Add cache control for eMMC4.5 device")
Fixes: 130206a615a9 ("mmc: core: Add support for cache ctrl for SD cards")
Depends-on: 97fce126e279 ("mmc: block: Issue a cache flush only when it's enabled")
Reviewed-by: Avri Altman &lt;Avri.Altman@wdc.com&gt;
Signed-off-by: Michael Wu &lt;michael@allwinnertech.com&gt;
Link: https://lore.kernel.org/r/20220331073223.106415-1-michael@allwinnertech.com
[Ulf: Re-wrote the commit message]
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: renesas_sdhi: don't overwrite TAP settings when HS400 tuning is complete</title>
<updated>2022-04-13T18:03:19+00:00</updated>
<author>
<name>Wolfram Sang</name>
<email>wsa+renesas@sang-engineering.com</email>
</author>
<published>2022-04-04T11:49:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3984ce2d77fe837ba20ca2a3e6b882d170f2416e'/>
<id>urn:sha1:3984ce2d77fe837ba20ca2a3e6b882d170f2416e</id>
<content type='text'>
commit 03e59b1e2f56245163b14c69e0a830c24b1a3a47 upstream.

When HS400 tuning is complete and HS400 is going to be activated, we
have to keep the current number of TAPs and should not overwrite them
with a hardcoded value. This was probably a copy&amp;paste mistake when
upporting HS400 support from the BSP.

Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
Reported-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220404114902.12175-1-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: mmci: stm32: correctly check all elements of sg list</title>
<updated>2022-04-13T18:03:19+00:00</updated>
<author>
<name>Yann Gautier</name>
<email>yann.gautier@foss.st.com</email>
</author>
<published>2022-03-17T11:19:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d3b7f470776cd3be0e8db9c1c013e487d9ad8479'/>
<id>urn:sha1:d3b7f470776cd3be0e8db9c1c013e487d9ad8479</id>
<content type='text'>
commit 0d319dd5a27183b75d984e3dc495248e59f99334 upstream.

Use sg and not data-&gt;sg when checking sg list elements. Else only the
first element alignment is checked.
The last element should be checked the same way, for_each_sg already set
sg to sg_next(sg).

Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant")
Cc: stable@vger.kernel.org
Signed-off-by: Yann Gautier &lt;yann.gautier@foss.st.com&gt;
Link: https://lore.kernel.org/r/20220317111944.116148-2-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: block: Check for errors after write on SPI</title>
<updated>2022-04-13T18:03:19+00:00</updated>
<author>
<name>Christian Löhle</name>
<email>CLoehle@hyperstone.com</email>
</author>
<published>2022-03-24T14:18:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=52f59397d9896e62d1763f67626af5de8cdd014a'/>
<id>urn:sha1:52f59397d9896e62d1763f67626af5de8cdd014a</id>
<content type='text'>
commit 5d435933376962b107bd76970912e7e80247dcc7 upstream.

Introduce a SEND_STATUS check for writes through SPI to not mark
an unsuccessful write as successful.

Since SPI SD/MMC does not have states, after a write, the card will
just hold the line LOW until it is ready again. The driver marks the
write therefore as completed as soon as it reads something other than
all zeroes.
The driver does not distinguish from a card no longer signalling busy
and it being disconnected (and the line being pulled-up by the host).
This lead to writes being marked as successful when disconnecting
a busy card.
Now the card is ensured to be still connected by an additional CMD13,
just like non-SPI is ensured to go back to TRAN state.

While at it and since we already poll for the post-write status anyway,
we might as well check for SPIs error bits (any of them).

The disconnecting card problem is reproducable for me after continuous
write activity and randomly disconnecting, around every 20-50 tries
on SPI DS for some card.

Fixes: 7213d175e3b6f ("MMC/SD card driver learns SPI")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Loehle &lt;cloehle@hyperstone.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/76f6f5d2b35543bab3dfe438f268609c@hyperstone.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning"</title>
<updated>2022-04-13T18:03:19+00:00</updated>
<author>
<name>Pali Rohár</name>
<email>pali@kernel.org</email>
</author>
<published>2022-03-18T14:14:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=00c7fae6537a3592976e30375e13882c54068e51'/>
<id>urn:sha1:00c7fae6537a3592976e30375e13882c54068e51</id>
<content type='text'>
commit 7e2646ed47542123168d43916b84b954532e5386 upstream.

This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f.

Commit 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization")
contains proper fix for the issue described in commit bb32e1987bc5 ("mmc:
sdhci-xenon: fix annoying 1.8V regulator warning").

Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable")
Cc: stable@vger.kernel.org # 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization")
Signed-off-by: Pali Rohár &lt;pali@kernel.org&gt;
Reviewed-by: Marek Behún &lt;kabel@kernel.org&gt;
Reviewed-by: Marcin Wojtas &lt;mw@semihalf.com&gt;
Link: https://lore.kernel.org/r/20220318141441.32329-1-pali@kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: rtsx: Fix build errors/warnings for unused variable</title>
<updated>2022-04-08T12:06:58+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2022-03-01T11:53:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=99a0c17db205e6fdca25441dda586d58d1993cdb'/>
<id>urn:sha1:99a0c17db205e6fdca25441dda586d58d1993cdb</id>
<content type='text'>
commit 3dd9a926ec2308e49445f22abef149fc64e9332e upstream.

The struct device *dev, is no longer needed at various functions, let's
therefore drop it to fix the build errors/warnings.

Fixes: 7570fb41e450 ("mmc: rtsx: Let MMC core handle runtime PM")
Cc: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Link: https://lore.kernel.org/r/20220301115300.64332-1-ulf.hansson@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: rtsx: Let MMC core handle runtime PM</title>
<updated>2022-04-08T12:06:58+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2022-02-16T05:54:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1016d5af150630b8f9e0680d045b0a4cdf67cc62'/>
<id>urn:sha1:1016d5af150630b8f9e0680d045b0a4cdf67cc62</id>
<content type='text'>
commit 7570fb41e450ba37bf9335fe3751fa9f502c30fa upstream.

Since MMC core handles runtime PM reference counting, we can avoid doing
redundant runtime PM work in the driver. That means the only thing
commit 5b4258f6721f ("misc: rtsx: rts5249 support runtime PM") misses is
to always enable runtime PM, to let its parent driver enable ASPM in the
runtime idle routine.

Fixes: 7499b529d97f ("mmc: rtsx: Use pm_runtime_{get,put}() to handle runtime PM")
Reviewed-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Link: https://lore.kernel.org/r/20220216055435.2335297-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: rtsx: Use pm_runtime_{get,put}() to handle runtime PM</title>
<updated>2022-04-08T12:06:54+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2022-01-25T05:50:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=24b8b217185d4db23bd684d31f70efc293775028'/>
<id>urn:sha1:24b8b217185d4db23bd684d31f70efc293775028</id>
<content type='text'>
commit 7499b529d97f752124fa62fefa1d6d44b371215a upstream.

Commit 5b4258f6721f ("misc: rtsx: rts5249 support runtime PM") doesn't
use pm_runtime_{get,put}() helpers when it should, so the RPM refcount
keeps at zero, hence its parent driver, rtsx_pci, has to do lots of
weird tricks to keep it from runtime suspending.

So use those helpers at right places to properly manage runtime PM.

Fixes: 5b4258f6721f ("misc: rtsx: rts5249 support runtime PM")
Cc: Ricky WU &lt;ricky_wu@realtek.com&gt;
Tested-by: Ricky WU &lt;ricky_wu@realtek.com&gt;
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Link: https://lore.kernel.org/r/20220125055010.1866563-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: host: Return an error when -&gt;enable_sdio_irq() ops is missing</title>
<updated>2022-04-08T12:06:42+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2022-03-03T16:51:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b6283cc505cfc7f23c9d6e062a948e0455e35270'/>
<id>urn:sha1:b6283cc505cfc7f23c9d6e062a948e0455e35270</id>
<content type='text'>
[ Upstream commit d6c9219ca1139b74541b2a98cee47a3426d754a9 ]

Even if the current WARN() notifies the user that something is severely
wrong, we can still end up in a PANIC() when trying to invoke the missing
-&gt;enable_sdio_irq() ops. Therefore, let's also return an error code and
prevent the host from being added.

While at it, move the code into a separate function to prepare for
subsequent changes and for further host caps validations.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Link: https://lore.kernel.org/r/20220303165142.129745-1-ulf.hansson@linaro.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: davinci_mmc: Handle error for clk_enable</title>
<updated>2022-04-08T12:05:55+00:00</updated>
<author>
<name>Jiasheng Jiang</name>
<email>jiasheng@iscas.ac.cn</email>
</author>
<published>2022-03-08T07:14:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=92e34984703b934175c9727d99454c248f81d60c'/>
<id>urn:sha1:92e34984703b934175c9727d99454c248f81d60c</id>
<content type='text'>
[ Upstream commit 09e7af76db02c74f2a339b3cb2d95460fa2ddbe4 ]

As the potential failure of the clk_enable(),
it should be better to check it and return error
if fails.

Fixes: bbce5802afc5 ("davinci: mmc: updates to suspend/resume implementation")
Signed-off-by: Jiasheng Jiang &lt;jiasheng@iscas.ac.cn&gt;
Link: https://lore.kernel.org/r/20220308071415.1093393-1-jiasheng@iscas.ac.cn
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
