linux-kernel - 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 for Android: free password hash cracker in your pocket

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

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

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.

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.

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?

-Saravana