<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/mmc/core/mmc.c, branch v6.1</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-04-26T13:39:37+00:00</updated>
<entry>
<title>mmc: core: Add CIDs for cards to the entropy pool</title>
<updated>2022-04-26T13:39:37+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2022-04-25T20:54:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac9d25557dcc9fe90ed12bfbb6db401e892ca004'/>
<id>urn:sha1:ac9d25557dcc9fe90ed12bfbb6db401e892ca004</id>
<content type='text'>
To make the entropy pool a bit better we can toss in the
CID for eMMC and SD cards into it, usually the serial
number portion is at least unique.

This does not count as improvement of the entropy but
in practice it makes it a bit more random to mix in these
numbers.

Cc: Theodore Ts'o &lt;tytso@mit.edu&gt;
Acked-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Link: https://lore.kernel.org/r/20220425205442.1347837-1-linus.walleij@linaro.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'fixes' into next</title>
<updated>2022-04-26T12:05:26+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2022-04-26T12:05:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c25a7e5d18ba6e88932ef8ebcf6635cca630d032'/>
<id>urn:sha1:c25a7e5d18ba6e88932ef8ebcf6635cca630d032</id>
<content type='text'>
</content>
</entry>
<entry>
<title>mmc: improve API to make clear hw_reset callback is for cards</title>
<updated>2022-04-26T12:05:20+00:00</updated>
<author>
<name>Wolfram Sang</name>
<email>wsa+renesas@sang-engineering.com</email>
</author>
<published>2022-04-08T08:00:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=32f18e596141f40dbc5d8700b2730371ffd3055f'/>
<id>urn:sha1:32f18e596141f40dbc5d8700b2730371ffd3055f</id>
<content type='text'>
To make it unambiguous that the hw_reset callback is for cards and not
for controllers, we add 'card' to the callback name and convert all
users in one go. We keep the argument as mmc_host, though, because the
callback is used very early when mmc_card is not yet populated.

Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Link: https://lore.kernel.org/r/20220408080045.6497-4-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Set HS clock speed before sending HS CMD13</title>
<updated>2022-04-26T11:55:50+00:00</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-04-22T17:08:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4bc31edebde51fcf8ad0794763b8679a7ecb5ec0'/>
<id>urn:sha1:4bc31edebde51fcf8ad0794763b8679a7ecb5ec0</id>
<content type='text'>
Way back in commit 4f25580fb84d ("mmc: core: changes frequency to
hs_max_dtr when selecting hs400es"), Rockchip engineers noticed that
some eMMC don't respond to SEND_STATUS commands very reliably if they're
still running at a low initial frequency. As mentioned in that commit,
JESD84-B51 P49 suggests a sequence in which the host:
1. sets HS_TIMING
2. bumps the clock ("&lt;= 52 MHz")
3. sends further commands

It doesn't exactly require that we don't use a lower-than-52MHz
frequency, but in practice, these eMMC don't like it.

The aforementioned commit tried to get that right for HS400ES, although
it's unclear whether this ever truly worked as committed into mainline,
as other changes/refactoring adjusted the sequence in conflicting ways:

08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode
switch")

53e60650f74e ("mmc: core: Allow CMD13 polling when switching to HS mode
for mmc")

In any case, today we do step 3 before step 2. Let's fix that, and also
apply the same logic to HS200/400, where this eMMC has problems too.

Resolves errors like this seen when booting some RK3399 Gru/Scarlet
systems:

[    2.058881] mmc1: CQHCI version 5.10
[    2.097545] mmc1: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA
[    2.209804] mmc1: mmc_select_hs400es failed, error -84
[    2.215597] mmc1: error -84 whilst initialising MMC card
[    2.417514] mmc1: mmc_select_hs400es failed, error -110
[    2.423373] mmc1: error -110 whilst initialising MMC card
[    2.605052] mmc1: mmc_select_hs400es failed, error -110
[    2.617944] mmc1: error -110 whilst initialising MMC card
[    2.835884] mmc1: mmc_select_hs400es failed, error -110
[    2.841751] mmc1: error -110 whilst initialising MMC card

Ealier versions of this patch bumped to 200MHz/HS200 speeds too early,
which caused issues on, e.g., qcom-msm8974-fairphone-fp2. (Thanks for
the report Luca!) After a second look, it appears that aligns with
JESD84 / page 45 / table 28, so we need to keep to lower (HS / 52 MHz)
rates first.

Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch")
Fixes: 53e60650f74e ("mmc: core: Allow CMD13 polling when switching to HS mode for mmc")
Fixes: 4f25580fb84d ("mmc: core: changes frequency to hs_max_dtr when selecting hs400es")
Cc: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Link: https://lore.kernel.org/linux-mmc/11962455.O9o76ZdvQC@g550jk/
Reported-by: Luca Weiss &lt;luca@z3ntu.xyz&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Tested-by: Luca Weiss &lt;luca@z3ntu.xyz&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220422100824.v4.1.I484f4ee35609f78b932bd50feed639c29e64997e@changeid
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Drop HS400 caps unless 8-bit bus is supported too</title>
<updated>2022-03-15T09:25:21+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2022-03-03T16:51:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=23e1b8c15b3ab402bc422338073afc7cf2351788'/>
<id>urn:sha1:23e1b8c15b3ab402bc422338073afc7cf2351788</id>
<content type='text'>
When mmc_select_hs400es() tries to switch to the HS400 ES mode, it may bail
out early if the host doesn't support an 8-bit buswidth, as it's required
for the HS400 mode.

To improve the situation, let's instead drop the HS400 bits from the
capability field if the 8-bit bus isn't supported. In this way, we allow
the mmc initialization to continue by trying a lower speed mode.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Link: https://lore.kernel.org/r/20220303165151.129806-1-ulf.hansson@linaro.org
</content>
</entry>
<entry>
<title>mmc: core: Improve fallback to speed modes if eMMC HS200 fails</title>
<updated>2022-03-15T09:24:55+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2022-03-03T16:45:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3b6c472822f8bdeaa3cea8290f5b4a210dca5585'/>
<id>urn:sha1:3b6c472822f8bdeaa3cea8290f5b4a210dca5585</id>
<content type='text'>
In the error path of mmc_select_hs200() we are trying our best to restore
the card/host into a valid state. This makes sense, especially if we
encounter a simple switch error (-EBADMSG). However, rather than then
continue with using the legacy speed mode, let's try the other better speed
modes first. Additionally, let's update the card-&gt;mmc_avail_type to avoid
us from trying a broken HS200 mode again.

In an Amlogic S905W based TV box where the switch to HS200 mode fails for
the eMMC, this allows us to use the eMMC in DDR mode in favor of the legacy
mode, which greatly improves the performance.

Suggested-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Tested-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Link: https://lore.kernel.org/r/20220303164522.129583-1-ulf.hansson@linaro.org
</content>
</entry>
<entry>
<title>Merge branch 'fixes' into next</title>
<updated>2022-03-07T11:53:29+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2022-03-07T11:53:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7a9f778c7f5ab2539085c49c63a898ee0557524e'/>
<id>urn:sha1:7a9f778c7f5ab2539085c49c63a898ee0557524e</id>
<content type='text'>
</content>
</entry>
<entry>
<title>mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND</title>
<updated>2022-03-07T10:47:39+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2022-03-04T10:56:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1760fdb6fe9f796fbdb9b4106b3e0bbacc16b55c'/>
<id>urn:sha1:1760fdb6fe9f796fbdb9b4106b3e0bbacc16b55c</id>
<content type='text'>
Commit 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1"),
significantly decreased the polling period from ~10-12ms into just a couple
of us. The purpose was to decrease the total time spent in the busy polling
loop, but unfortunate it has lead to problems, that causes eMMC cards to
never gets out busy and thus fails to be initialized.

To fix the problem, but also to try to keep some of the new improved
behaviour, let's start by using a polling period of 1-2ms, which then
increases for each loop, according to common polling loop in
__mmc_poll_for_busy().

Reported-by: Jean Rene Dawin &lt;jdawin@math.uni-bielefeld.de&gt;
Reported-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Cc: Huijin Park &lt;huijin.park@samsung.com&gt;
Fixes: 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1")
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Tested-by: Jean Rene Dawin &lt;jdawin@math.uni-bielefeld.de&gt;
Tested-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Link: https://lore.kernel.org/r/20220304105656.149281-1-ulf.hansson@linaro.org
</content>
</entry>
<entry>
<title>mmc: core: use sysfs_emit() instead of sprintf()</title>
<updated>2022-02-28T12:06:23+00:00</updated>
<author>
<name>Sergey Shtylyov</name>
<email>s.shtylyov@omp.ru</email>
</author>
<published>2022-02-08T12:02:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f5d8a5fe77ce933f53eb8f2e22bb7a1a2019ea11'/>
<id>urn:sha1:f5d8a5fe77ce933f53eb8f2e22bb7a1a2019ea11</id>
<content type='text'>
sprintf() (still used in the MMC core for the sysfs output) is vulnerable
to the buffer overflow.  Use the new-fangled sysfs_emit() instead.

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.

Signed-off-by: Sergey Shtylyov &lt;s.shtylyov@omp.ru&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/717729b2-d65b-c72e-9fac-471d28d00b5a@omp.ru
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: change __mmc_poll_for_busy() parameter type</title>
<updated>2021-12-14T20:35:24+00:00</updated>
<author>
<name>Huijin Park</name>
<email>huijin.park@samsung.com</email>
</author>
<published>2021-11-04T06:32:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2ebbdace5cc05caea9d12f536a8d0b9a3d930a29'/>
<id>urn:sha1:2ebbdace5cc05caea9d12f536a8d0b9a3d930a29</id>
<content type='text'>
This patch changes the __mmc_poll_for_busy() first parameter type
from 'struct mmc_card*' to 'struct mmc_host*'.
Because the function refers only 'struct mmc_host' to get hostname.

Signed-off-by: Huijin Park &lt;huijin.park@samsung.com&gt;
Link: https://lore.kernel.org/r/20211104063231.2115-2-huijin.park@samsung.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
</feed>
