All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.