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

Message-ID: <CAPDyKFqUiydk3hHiKZ92e-W2tC4yv-XhGSz20KYYsTuZu0rWuQ@mail.gmail.com>
Date:   Mon, 31 Jan 2022 16:45:35 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Saravana Kannan <saravanak@...gle.com>
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 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.

>
> 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.

>
> If it's supposed to be "we'll use card_busy() if
> MMC_CAP_WAIT_WHILE_BUSY isn't set", then why do we have some mmc host
> drivers that have both?
>
> What am I misunderstanding?

There are some additional complexity for the corresponding code. This
has mostly ended up there because we also need to deal with mmc
controller's HW limitations around this feature.

For example, some mmc controllers have a HW limit for the length of
the timeout that can be set. If the needed timeout is longer than what
can be supported, we can't use IRQ based busy completion.

Did this make it more clear?

>
> -Saravana

Kind regards
Uffe