From: Daniel Kucera <linux-mmc@danman.eu>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc@vger.kernel.org
Subject: Re: [PATCH v4] mmc: core: allow detection of locked cards
Date: Thu, 20 Jun 2024 14:59:15 +0200 [thread overview]
Message-ID: <c89d8a0c170fa3bc8593bfde25b07e4d@danman.eu> (raw)
In-Reply-To: <CAPDyKFpuJexp_1hgKhJ3b8VCx+PwwhAQscbJT5-44Re0xmbxrg@mail.gmail.com>
On 2024-06-20 14:38, Ulf Hansson wrote:
> On Thu, 6 Jun 2024 at 15:12, <linux-mmc@danman.eu> wrote:
>>
>> From: Daniel Kucera <linux-mmc@danman.eu>
>>
>> Locked SD card will not reply to SEND_SCR or SD_STATUS commands
>> so it was failing to initialize previously. When skipped,
>> the card will get initialized and CMD42 can be sent using
>> ioctl to unlock the card or remove password protection.
>> For eMMC, this is not necessary because all initialization
>> commands are allowed in locked state.
>> Until unlocked, all read/write calls will timeout.
>
> Skipping the commands above, only means the card gets partially
> initialized.
Correct, but it's an improvement in comparison to current state.
> Leaving a card in that state seems fragile.
Fragile in what sense? Nothing can happen to the card as it is locked.
> What will
> happen to upper block layers and filesystems when trying to access it?
Everything will simply time-out.
>
> Several years ago Al Cooper made an attempt [1] to manage the
> unlocking of the card during initialization, by finding the password
> through the "keys" subsystem. The series didn't really make it to the
> upstream kernel, but overall the approach seemed to make sense to me.
> It should allow us to complete the initialization of the card inside
> the kernel and prevent unnecessary complexity for userspace to manage.
Yes, he did a great work but obviously no-one got too excited to
review/merge
his work. His solution was complex.
Mine targets the smallest change possible to make it work at least.
I wanted to avoid a solution that would be hard to test, review and
maintain.
Especially when there is only a small interest in the feature.
> Perhaps you can have a closer look at that series and see if it's
> possible to update it?
I don't think I have the skills to revive his work.
>
> Kind regards
> Uffe
BR
Daniel
>
> [1]
> https://lore.kernel.org/linux-mmc/1433526147-25941-1-git-send-email-alcooperx@gmail.com/
>
>>
>> Signed-off-by: Daniel Kucera <linux-mmc@danman.eu>
>> ---
>> drivers/mmc/core/sd.c | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
>> index 1c8148cdd..ae821df7d 100644
>> --- a/drivers/mmc/core/sd.c
>> +++ b/drivers/mmc/core/sd.c
>> @@ -928,8 +928,19 @@ int mmc_sd_setup_card(struct mmc_host *host,
>> struct mmc_card *card,
>> bool reinit)
>> {
>> int err;
>> + u32 card_status;
>>
>> - if (!reinit) {
>> + err = mmc_send_status(card, &card_status);
>> + if (err){
>> + pr_err("%s: unable to get card status\n",
>> mmc_hostname(host));
>> + return err;
>> + }
>> +
>> + if (card_status & R1_CARD_IS_LOCKED){
>> + pr_warn("%s: card is locked\n", mmc_hostname(host));
>> + }
>> +
>> + if (!reinit && !(card_status & R1_CARD_IS_LOCKED)) {
>> /*
>> * Fetch SCR from card.
>> */
>> --
>> 2.34.1
>>
next prev parent reply other threads:[~2024-06-20 12:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 13:12 [PATCH v4] mmc: core: allow detection of locked cards linux-mmc
2024-06-20 12:38 ` Ulf Hansson
2024-06-20 12:59 ` Daniel Kucera [this message]
2024-06-20 14:32 ` Ulf Hansson
2024-06-20 15:31 ` Christian Loehle
2024-06-20 18:15 ` Daniel Kucera
2024-06-21 7:16 ` Avri Altman
2024-07-01 8:33 ` Daniel Kucera
2024-07-08 13:32 ` Ulf Hansson
2024-07-08 13:43 ` Ulf Hansson
2024-07-09 20:06 ` Avri Altman
2024-07-10 5:21 ` Daniel Kucera
2024-07-10 5:49 ` Avri Altman
2024-07-10 13:26 ` Ulf Hansson
2024-07-13 20:50 ` Daniel Kucera
2024-07-14 6:49 ` Avri Altman
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=c89d8a0c170fa3bc8593bfde25b07e4d@danman.eu \
--to=linux-mmc@danman.eu \
--cc=linux-mmc@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox