archive mirror
 help / color / mirror / Atom feed
From: "Christian Löhle" <>
To: Ulf Hansson <>
Cc: "" <>,
	"" <>,
	Avri Altman <>,
	Christoph Hellwig <>
Subject: Re: [PATCH] mmc: block: Differentiate busy and non-TRAN state
Date: Tue, 6 Jul 2021 09:09:16 +0000	[thread overview]
Message-ID: <CWXP265MB26803EFAC659676EC0914F97C41B9@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <>

Hey Uffe,

>> +static int is_return_to_tran_cmd(struct mmc_command *cmd)
>> +{
>> +       /*
>> +        * Cards will never return to TRAN after completing
>> +        * identification commands or MMC_SEND_STATUS if they are not selected.
>> +        */
>> +       switch (cmd->opcode) {
>> +       case MMC_GO_IDLE_STATE:
>> +       case MMC_SEND_OP_COND:
>> +       case MMC_ALL_SEND_CID:
>> +       case MMC_SET_RELATIVE_ADDR:
>> +       case MMC_SET_DSR:
>> +       case MMC_SLEEP_AWAKE:
>> +       case MMC_SELECT_CARD:
>> +       case MMC_SEND_CSD:
>> +       case MMC_SEND_CID:
>> +       case MMC_SEND_STATUS:
>> +       case MMC_GO_INACTIVE_STATE:
>> +       case MMC_APP_CMD:
>> +               return false;
>> +       default:
>> +               return true;
>> +       }
>> +}
>What exactly are you trying to do with the user space program through
>the mmc ioctl with all these commands? The mmc ioctl interface is not
>designed to be used like that.
>In principle, it looks like we should support a complete
>re-initialization of the card. I am sorry, but no thanks! This doesn't
>work, but more importantly, this should be managed solely by the
>kernel, in my opinion.

Doing initialization itself through ioctl is silly, I agree, and does
not work on other ends. This patch is not about that. it just explicitly disables
any CMD13 polling for TRAN for some of those commands. the behavior
for such commands thus is the same as without the patch.
The reason for this patch is to not run into the race condition that a 
following (ioctl) command will be rejected because the card is in e.g. PROG state
of a previous ioctl command. As stated earlier, I encountered this a lot when
doing a unlock force erase -> lock/set, in both scenarios, issued as two single
ioctl commands and bundled together.
But this race condition exists on any (non-R1b/ RPBM) currently. As there is
no CMD13 polling happening after the response (or whenever the driver marks
the request as done), the card's status is therefore generally unknown.

So in short I don;t want to do anything too crazy from userspace, but the
alternative now is to do like 100ms sleeps in the hope that the card is
actually finished with the issued command (not just the host driver so to say).

Kind Regards,
Hyperstone GmbH | Line-Eid-Strasse 3 | 78467 Konstanz
Managing Directors: Dr. Jan Peter Berns.
Commercial register of local courts: Freiburg HRB381782

  reply	other threads:[~2021-07-06  9:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01  9:43 [PATCH] mmc: block: Differentiate busy and non-TRAN state Christian Löhle
2021-07-02  7:43 ` Christoph Hellwig
2021-07-06  8:20 ` Christian Löhle
2021-07-06  8:40   ` Ulf Hansson
2021-07-06  9:09     ` Christian Löhle [this message]
2021-07-06  9:34       ` Ulf Hansson
2021-07-07  6:49       ` Avri Altman
2021-07-07  8:27         ` [PATCHv2] mmc: block: Differentiate busy and PROG state Christian Löhle
2021-07-07 11:57           ` Ulf Hansson
2021-07-07 14:36             ` Christian Löhle
2021-08-09 15:16               ` Ulf Hansson
2021-07-07  9:01         ` [PATCH] mmc: block: Differentiate busy and non-TRAN state Christian Löhle
2021-07-07 10:16           ` Avri Altman
2021-07-07 14:42             ` Christian Löhle

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CWXP265MB26803EFAC659676EC0914F97C41B9@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).