From: <yann.gautier@foss.st.com>
To: <ulf.hansson@linaro.org>
Cc: <linux@armlinux.org.uk>, <linus.walleij@linaro.org>,
<ludovic.barre@foss.st.com>, <per.forlin@linaro.org>,
<huyue2@yulong.com>, <wsa+renesas@sang-engineering.com>,
<vbadigan@codeaurora.org>, <adrian.hunter@intel.com>,
<p.zabel@pengutronix.de>, <marex@denx.de>, <swboyd@chromium.org>,
<linux-mmc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<yann.gautier@foss.st.com>
Subject: [PATCH 0/2] mmc: mmci/mmc_test: update mmc_erase management
Date: Thu, 4 Feb 2021 13:05:45 +0100 [thread overview]
Message-ID: <20210204120547.15381-1-yann.gautier@foss.st.com> (raw)
From: Yann Gautier <yann.gautier@foss.st.com>
We are facing issues when testing STM32MP157C-EV1 board with latest MMC
developments.
The commands with R1B responses weren't correctly managed, needing
MMC_CAP_NEED_RSP_BUSY.
The Ux500 platforms have the same busy detection feature, so this
flag is enabled for them too. But this change has only been tested
on STM32MP1 boards, as I don't have ux500 hardware.
The mmc_test should rely on the erase argument set in the framework,
when using MMC_ERASE command.
Yann Gautier (2):
mmc: mmci: enable MMC_CAP_NEED_RSP_BUSY
mmc: mmc_test: use erase_arg for mmc_erase command
drivers/mmc/core/mmc_test.c | 2 +-
drivers/mmc/host/mmci.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.17.1
next reply other threads:[~2021-02-04 12:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-04 12:05 yann.gautier [this message]
2021-02-04 12:05 ` [PATCH 1/2] mmc: mmci: enable MMC_CAP_NEED_RSP_BUSY yann.gautier
2021-02-04 12:26 ` Marek Vasut
2021-02-04 12:54 ` Yann GAUTIER
2021-02-04 13:07 ` Marek Vasut
2021-02-05 9:53 ` Ulf Hansson
2021-02-05 12:19 ` Yann GAUTIER
2021-02-08 12:16 ` Yann GAUTIER
2021-02-08 13:31 ` Yann GAUTIER
2021-02-08 15:03 ` Ulf Hansson
2021-02-09 14:01 ` Yann Gautier
2021-02-10 12:03 ` Ulf Hansson
2021-02-04 12:05 ` [PATCH 2/2] mmc: mmc_test: use erase_arg for mmc_erase command yann.gautier
2021-02-05 6:33 ` Adrian Hunter
2021-02-05 9:05 ` Yann GAUTIER
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210204120547.15381-1-yann.gautier@foss.st.com \
--to=yann.gautier@foss.st.com \
--cc=adrian.hunter@intel.com \
--cc=huyue2@yulong.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=ludovic.barre@foss.st.com \
--cc=marex@denx.de \
--cc=p.zabel@pengutronix.de \
--cc=per.forlin@linaro.org \
--cc=swboyd@chromium.org \
--cc=ulf.hansson@linaro.org \
--cc=vbadigan@codeaurora.org \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.