linux-kernel - Re: [PATCH] mmc: core: Restore (almost) the busy polling for MMC_SEND_OP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 4 May 2022 07:46:52 +0200
From:   Jean Rene Dawin <jdawin@...h.uni-bielefeld.de>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     "H . Nikolaus Schaller" <hns@...delico.com>,
        Huijin Park <huijin.park@...sung.com>,
        linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org
Subject: Re: [PATCH] mmc: core: Restore (almost) the busy polling for
 MMC_SEND_OP_COND

Ulf Hansson wrote on Mon  7/03/22 13:17:
> On Fri, 4 Mar 2022 at 11:57, Ulf Hansson <ulf.hansson@...aro.org> wrote:
> >
> > 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 <jdawin@...h.uni-bielefeld.de>
> > Reported-by: H. Nikolaus Schaller <hns@...delico.com>
> > Cc: Huijin Park <huijin.park@...sung.com>
> > Fixes: 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1")
> > Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
> > ---
> > 
> > Jean Rene and H. Nikolaus, if this doesn't work, please try extending the
> > the MMC_OP_COND_PERIOD_US a bit, to so see if we can find a value that always
> > works.
> > 
> > Kind regards
> > Uffe

> 
> Applied for fixes and by adding two tested-by tags from you, thanks!
> 
> Kind regards
> Uffe

Hi,

with the current value of MMC_OP_COND_PERIOD_US = 1ms I still see

mmc1: Card stuck being busy! __mmc_poll_for_busy
mmc1: error -110 doing runtime resume

regularly. The same with 2ms. Setting it to 4ms makes the messages go
away. Would it be ok to increase MMC_OP_COND_PERIOD_US to 4ms?


---
 drivers/mmc/core/mmc_ops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 180d7e9d3400..1fd57f342842 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -21,7 +21,7 @@

 #define MMC_BKOPS_TIMEOUT_MS           (120 * 1000) /* 120s */
 #define MMC_SANITIZE_TIMEOUT_MS                (240 * 1000) /* 240s */
-#define MMC_OP_COND_PERIOD_US          (1 * 1000) /* 1ms */
+#define MMC_OP_COND_PERIOD_US          (4 * 1000) /* 1ms */
 #define MMC_OP_COND_TIMEOUT_MS         1000 /* 1s */

 static const u8 tuning_blk_pattern_4bit[] = {
--
2.35.1


Regards,
Jean Rene