Linux MultiMedia Card development
 help / color / mirror / Atom feed
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
>> 

  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