[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Jul 2021 10:16:41 +0000
From: Avri Altman <Avri.Altman@....com>
To: Christian Löhle <CLoehle@...erstone.com>,
Ulf Hansson <ulf.hansson@...aro.org>
CC: "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"hch@...radead.org" <hch@...radead.org>
Subject: RE: [PATCH] mmc: block: Differentiate busy and non-TRAN state
> Hey Avri,
>
> >Are you using mmc-utils?
> No, Im accessing the ioctl interface with my own application.
>
> >Can you share exactly the sequence of commands you are sending?
>
> The one I initially encountered was, as stated earlier, a Unlock-Force Erase
> into a new Lock with set password. Basically any R1 (no b) command that
> transitions to PROG, so behaves like a write command, could trigger this.
> But obviously Unlock force erase is the best example, as a full erase will
> take quite some time and many (all?) cards will not accept new commands
> (i.e. stay in PROG) until the erase has actually completed. The current
> code will not check anything for CMD42 after the response.
> I have not hit the race condition with anything but CMD42.
>
> So to be verbose:
> CMD16 - CMD42 Set PW - (CMD16)* - CMD42 Unlock Force Erase - (CMD42
> Set PW)+
> * May be omitted if you craft the CMD42 carefully (i.e. equal data size)
> + is pretty much irrelevant, can be replaced with anything that is illegal in
> PROG.
Oh, OK. Interesting.
This functionality is missing in mmc-utils.
While at it, I encourage you to consider adding it.
Thanks,
Avri
>
> >Again, can you share the sequence of the commands you are using?
> >
> >Thanks,
> >Avri
> Hyperstone GmbH | Line-Eid-Strasse 3 | 78467 Konstanz
> Managing Directors: Dr. Jan Peter Berns.
> Commercial register of local courts: Freiburg HRB381782
Powered by blists - more mailing lists