<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/mmc/core/core.c, branch linux-5.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-06-25T03:34:44Z</updated>
<entry>
<title>mmc: core: API to temporarily disable retuning for SDIO CRC errors</title>
<updated>2019-06-25T03:34:44Z</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2019-06-17T17:56:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2ea454840793b8c8022d242cba3ad8f92cae5313'/>
<id>urn:sha1:2ea454840793b8c8022d242cba3ad8f92cae5313</id>
<content type='text'>
commit 0a55f4ab9678413a01e740c86e9367ba0c612b36 upstream.

Normally when the MMC core sees an "-EILSEQ" error returned by a host
controller then it will trigger a retuning of the card.  This is
generally a good idea.

However, if a command is expected to sometimes cause transfer errors
then these transfer errors shouldn't cause a re-tuning.  This
re-tuning will be a needless waste of time.  One example case where a
transfer is expected to cause errors is when transitioning between
idle (sometimes referred to as "sleep" in Broadcom code) and active
state on certain Broadcom WiFi SDIO cards.  Specifically if the card
was already transitioning between states when the command was sent it
could cause an error on the SDIO bus.

Let's add an API that the SDIO function drivers can call that will
temporarily disable the auto-tuning functionality.  Then we can add a
call to this in the Broadcom WiFi driver and any other driver that
might have similar needs.

NOTE: this makes the assumption that the card is already tuned well
enough that it's OK to disable the auto-retuning during one of these
error-prone situations.  Presumably the driver code performing the
error-prone transfer knows how to recover / retry from errors.  ...and
after we can get back to a state where transfers are no longer
error-prone then we can enable the auto-retuning again.  If we truly
find ourselves in a case where the card needs to be retuned sometimes
to handle one of these error-prone transfers then we can always try a
few transfers first without auto-retuning and then re-try with
auto-retuning if the first few fail.

Without this change on rk3288-veyron-minnie I periodically see this in
the logs of a machine just sitting there idle:
  dwmmc_rockchip ff0d0000.dwmmc: Successfully tuned phase to XYZ

Cc: stable@vger.kernel.org #v4.18+
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Acked-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
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:fix a bug when max_discard is 0</title>
<updated>2019-03-01T08:50:10Z</updated>
<author>
<name>Jiong Wu</name>
<email>lohengrin1024@gmail.com</email>
</author>
<published>2019-02-28T16:18:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d4721339dcca7def04909a8e60da43c19a24d8bf'/>
<id>urn:sha1:d4721339dcca7def04909a8e60da43c19a24d8bf</id>
<content type='text'>
The original purpose of the code I fix is to replace max_discard with
max_trim if max_trim is less than max_discard. When max_discard is 0
we should replace max_discard with max_trim as well, because
max_discard equals 0 happens only when the max_do_calc_max_discard
process is overflowed, so if mmc_can_trim(card) is true, max_discard
should be replaced by an available max_trim.
However, in the original code, there are two lines of code interfere
the right process.
1) if (max_discard &amp;&amp; mmc_can_trim(card))
when max_discard is 0, it skips the process checking if max_discard
needs to be replaced with max_trim.
2) if (max_trim &lt; max_discard)
the condition is false when max_discard is 0. it also skips the process
that replaces max_discard with max_trim, in fact, we should replace the
0-valued max_discard with max_trim.

Signed-off-by: Jiong Wu &lt;Lohengrin1024@gmail.com&gt;
Fixes: b305882fbc87 (mmc: core: optimize mmc_calc_max_discard)
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'fixes' into next</title>
<updated>2019-02-28T08:16:18Z</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2019-02-28T08:16:18Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=82b6248705cccc4341b4c1d4a80a70f018198db0'/>
<id>urn:sha1:82b6248705cccc4341b4c1d4a80a70f018198db0</id>
<content type='text'>
</content>
</entry>
<entry>
<title>mmc: core: Add sd discard timeout</title>
<updated>2019-02-28T08:16:12Z</updated>
<author>
<name>Avri Altman</name>
<email>avri.altman@wdc.com</email>
</author>
<published>2019-02-26T15:10:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ad9be7fff3e729287f61a2a5e811c03090003fff'/>
<id>urn:sha1:ad9be7fff3e729287f61a2a5e811c03090003fff</id>
<content type='text'>
The busy timeout is 250msec per discard command.

Signed-off-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Add discard support to sd</title>
<updated>2019-02-28T08:16:12Z</updated>
<author>
<name>Avri Altman</name>
<email>avri.altman@wdc.com</email>
</author>
<published>2019-02-26T15:10:24Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bc47e2f6f9e261ea07c678c3cad76eb5590c0fea'/>
<id>urn:sha1:bc47e2f6f9e261ea07c678c3cad76eb5590c0fea</id>
<content type='text'>
SD spec v5.1 adds discard support. The flows and commands are similar to
mmc, so just set the discard arg in CMD38.

A host which supports DISCARD shall check if the DISCARD_SUPPORT (b313)
is set in the SD_STATUS register.  If the card does not support discard,
the host shall not issue DISCARD command, but ERASE command instead.

Post the DISCARD operation, the card may de-allocate the discarded
blocks partially or completely. So the host mustn't make any assumptions
concerning the content of the discarded region. This is unlike ERASE
command, in which the region is guaranteed to contain either '0's or
'1's, depends on the content of DATA_STAT_AFTER_ERASE (b55) in the scr
register.

One more important difference compared to ERASE is the busy timeout
which we will address on the next patch.

Signed-off-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Fix NULL ptr crash from mmc_should_fail_request</title>
<updated>2019-02-27T09:00:17Z</updated>
<author>
<name>Ritesh Harjani</name>
<email>riteshh@codeaurora.org</email>
</author>
<published>2019-02-22T13:51:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e5723f95d6b493dd437f1199cacb41459713b32f'/>
<id>urn:sha1:e5723f95d6b493dd437f1199cacb41459713b32f</id>
<content type='text'>
In case of CQHCI, mrq-&gt;cmd may be NULL for data requests (non DCMD).
In such case mmc_should_fail_request is directly dereferencing
mrq-&gt;cmd while cmd is NULL.
Fix this by checking for mrq-&gt;cmd pointer.

Fixes: 72a5af554df8 ("mmc: core: Add support for handling CQE requests")
Signed-off-by: Ritesh Harjani &lt;riteshh@codeaurora.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Convert mmc_align_data_size() into an SDIO specific function</title>
<updated>2019-02-25T16:20:21Z</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2019-02-13T19:03:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=eae343c290f78916b254972e85e0b419e55618f1'/>
<id>urn:sha1:eae343c290f78916b254972e85e0b419e55618f1</id>
<content type='text'>
The only user of mmc_align_data_size() is sdio_align_size(), which is
called from SDIO func drivers to let them distinguish, how to optimally
allocate data buffers.

Let's move mmc_align_data_size() close to the SDIO code as to make it
static, rename it to _sdio_align_size() and simplify its definition, all
with the purpose of clarifying that this is SDIO specific.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
</content>
</entry>
<entry>
<title>mmc: core: Move mmc_of_parse_voltage() to host.c</title>
<updated>2019-02-25T14:20:58Z</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2019-02-13T17:46:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9d2d24302e615e984034d2f60a4da739de6bd637'/>
<id>urn:sha1:9d2d24302e615e984034d2f60a4da739de6bd637</id>
<content type='text'>
MMC OF parsing functions, which parses various host DT properties, should
stay close to each other. Therefore, let's move mmc_of_parse_voltage()
close to mmc_of_parse() into host.c.

Additionally, there is no reason to build the code only when CONFIG_OF is
set, as there should be stub functions for the OF helpers that is being
used, so let's drop this condition as well.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Move regulator helpers to separate file</title>
<updated>2019-02-25T14:20:58Z</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2019-02-13T17:10:37Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=de13d5a44e61366ab5b75c111449ca284b6e3f5d'/>
<id>urn:sha1:de13d5a44e61366ab5b75c111449ca284b6e3f5d</id>
<content type='text'>
The mmc regulator helper functions, are placed in the extensive core.c
file.  In a step towards trying to create a better structure of files,
avoiding too many lines of code per file, let's move these helpers to a new
file, regulator.c.

Moreover, this within this context it makes sense to also drop the export
of mmc_vddrange_to_ocrmask(), but instead let's make it internal to the mmc
core.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Calculate the discard arg only once</title>
<updated>2019-02-25T07:40:58Z</updated>
<author>
<name>Avri Altman</name>
<email>avri.altman@wdc.com</email>
</author>
<published>2019-02-06T11:28:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=01904ff77676ca6c88e972906ed204a2dfbabab6'/>
<id>urn:sha1:01904ff77676ca6c88e972906ed204a2dfbabab6</id>
<content type='text'>
In MMC, the discard arg is a read-only ext_csd parameter - set it once
on card init. To be consistent, do that for SD as well even though its
discard arg is always 0x0.

Signed-off-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
</feed>
