linux-kernel - Re: Relation between MMC_CAP_WAIT_WHILE_BUSY and card

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] [day] [month] [year] [list]

Message-ID: <CAGETcx8UEqxtkA3-hSws463ekaXvGznvEa32GXtCkbLa3GL7ag@mail.gmail.com>
Date:   Tue, 1 Feb 2022 09:47:53 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Jaehoon Chung <jh80.chung@...sung.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Linux MMC List <linux-mmc@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: Relation between MMC_CAP_WAIT_WHILE_BUSY and card_busy()

On Tue, Feb 1, 2022 at 12:24 AM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Mon, 31 Jan 2022 at 21:15, Saravana Kannan <saravanak@...gle.com> wrote:
> >
> > On Mon, Jan 31, 2022 at 7:46 AM Ulf Hansson <ulf.hansson@...aro.org> wrote:
> > >
> > > On Wed, 26 Jan 2022 at 04:46, Saravana Kannan <saravanak@...gle.com> wrote:
> > > >
> > > > I'm trying to understand the MMC suspend path a bit.
> > > >
> > > > I looked at the commit message of 6fa79651cc808f68db6f6f297be5a950ccd5dffb.
> > > >
> > > > IIUC, if MMC_CAP_WAIT_WHILE_BUSY is set then the mmc framework is
> > > > going to depend on the card_busy() op to ensure correctness instead of
> > > > using the S_A_TIMEOUT value from the card.
> > >
> > > MMC_CAP_WAIT_WHILE_BUSY indicates whether the mmc controller supports
> > > IRQ based busy detection completion. In other words, the mmc host
> > > driver can receive an IRQ when busy signaling is completed on DAT0 by
> > > the eMMC card.
> > >
> > > However, to avoid waiting for the IRQ forever, there is a maximum
> > > timeout that is specified by the mmc core, for the particular command
> > > in question. For eMMC sleep, the S_A_TIMEOUT.
> >
> > Ah ok, thanks for the explanation.
> >
> > >
> > > >
> > > > But I see a lot of mmc host drivers that implement card_busy() but
> > > > don't set the MMC_CAP_WAIT_WHILE_BUSY flag. That doesn't seem right to
> > > > me if my understanding is correct.
> > >
> > > That's perfectly okay. MMC_CAP_WAIT_WHILE_BUSY is IRQ based, while the
> > > ->card_busy() ops is used to poll for busy completion.
> >
> > Yeah, it makes sense now.
> >
> > One thing I noticed when playing with some hardware is that during
> > suspend, when MMC_CAP_WAIT_WHILE_BUSY isn't set and we have a
> > card_busy() implementation, we don't seem to be using card_busy() op
> > and just always using the timeout from S_A_TIMEOUT. To be more
> > specific, I'm talking about this code path:
> > _mmc_suspend() -> mmc_sleep() -> mmc_delay() -> msleep()
> >
> > I'd think card_busy() could be used here if it's implemented. Is there
> > a reason for not using it in this path?
>
> That was exactly what commit 6fa79651cc80 ("mmc: core: Enable eMMC
> sleep commands to use HW busy polling") implemented. The commit was
> introduced in v5.14.
>
> If it doesn't work, there is a bug somewhere.

Ah I was checking an older kernel and meant to check the latest
mainline before I sent this email, but then forgot to do it. Thanks
for the pointer! Let me backport and see if it helps.

-Saravana