Message-ID: <CAPDyKFoH+B363wiPi6HoKg1VJXvJVNPoYaRTGXzEDgSTEg9TyA@mail.gmail.com>
Date: Tue, 16 Dec 2025 13:15:28 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Luke Wang <ziniu.wang_1@....com>
Cc: "axboe@...nel.dk" <axboe@...nel.dk>, 
	"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>, 
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "imx@...ts.linux.dev" <imx@...ts.linux.dev>
Subject: Re: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for
 certain Kingston eMMC devices

On Tue, 16 Dec 2025 at 11:02, Luke Wang <ziniu.wang_1@....com> wrote:
>
>
>
> > -----Original Message-----
> > From: Ulf Hansson <ulf.hansson@...aro.org>
> > Sent: Monday, December 15, 2025 11:38 PM
> > To: Luke Wang <ziniu.wang_1@....com>
> > Cc: axboe@...nel.dk; linux-block@...r.kernel.org; linux-
> > mmc@...r.kernel.org; linux-kernel@...r.kernel.org; imx@...ts.linux.dev
> > Subject: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for
> > certain Kingston eMMC devices
> >
> > Caution: This is an external email. Please take care when clicking links or
> > opening attachments. When in doubt, report the message using the 'Report
> > this email' button
> >
> >
> > On Mon, 15 Dec 2025 at 11:18, <ziniu.wang_1@....com> wrote:
> > >
> > > From: Luke Wang <ziniu.wang_1@....com>
> > >
> > > This patch series optimize secure erase performance for certain Kingston
> > > eMMC devices (IY2964 and IB2932) that take a fixed ~2 seconds per secure
> > > erase operation regardless of size.
> >
> > Well, that sounds to me like the eMMC isn't really erasing the blocks.
> > I wonder how "secure" this is in practice.
>
> Compared to other eMMC, 2 second secure erase time for 1GB is reasonable.
>
> Using the default 3.5MB secure erase chunk, the total time spent secure erasing 1GB:
> Sandisk SDINBDG4-32G-I 0.8s
> Micron MTFC32GAKAEEF-AIT 4.7s
> Longsys FEMDNN032G-C9A55 0.6s
>
> In fact, secure erase does not guarantee that data is physically erased. We previously encountered
> an issue with long secure trim times on the MTFC32GAKAEEF-AIT eMMC, and got confirmation
> from Micron:
> "Secure Erase (0x80000000) is treated as a simple Erase (0x00000000), while Secure
> Trim (0x80000001 + 0x80008000) and Trim (0x00000001) are treated differently. So, it is
> possible that Secure Trim really is the heaviest possible erase operation for the FW to execute. "
>
> And the eMMC 5.1 Spec:
> "NOTE Secure Erase is included for backwards compatibility. New system level implementations
> (based on v4.51 devices and beyond) should use Erase combined with Sanitize instead of secure erase."

Right, thanks for clarifying this! I do recall the complexity around this now.

>
> >
> > >
> > > Currently, a 1GB secure erase requires ~300 operations (limited by max
> > > discard size), taking ~10 minutes. With these changes, the same secure
> > > erase completes in a single operation, reducing time to just 2 seconds.
> >
> > Hmm, is the problem really the size or is it the timeout? Why does 300
> > operations to erase 1GB take ~10 minutes?
>
> I think the problem is caused by the fact that this Kingston eMMC secure erase
> small chunk need ~2 second. In contrast, other eMMC secure erase small chunk
> only take tens of milliseconds.

Okay! So it looks like using a card quirk, something along what you
propose in patch2 could make sense. I will have a closer look.

>
> Also, the calculated max discard is too small. For the I.MX8MN USBHC controller,
> host->max_busy_timeout is 2684ms, and the calculated max discard is always
> card->pref_erase - 1, which is 3.5MB.

I see, so regular REQ_OP_DISCARDs are suffering from similar problems
that are taking a very long time to complete?

Are you planning to make a similar card quirk for discards or what do
you have in mind?

>
> >
> > Can you please elaborate what happens on the mmc host driver level for
> > each operation. What mmc host driver/controller is being used? Does it
> > support MMC_CAP_WAIT_WHILE_BUSY or do we end up polling for
> > busy-completion in-between each command?
>
> This issue is found on IMX8MN-EVK, uSDHC controller. We end up polling for
> busy-completion in-between each command.
>
> I print some log during secure erasing:
> Without this patch
> [  126.760429] mmc2: starting CMD35 arg 01294000 flags 00000095
> [  126.766530] mmc2: starting CMD36 arg 01295bff flags 00000095
> [  126.772246] mmc2: starting CMD38 arg 80000000 flags 00000095
> [  126.777988] mmc2: mmc_poll_for_busy
> [  128.616245] mmc2: erase operation completes
> [  128.628511] mmc2: starting CMD35 arg 01295c00 flags 00000095
> [  128.634293] mmc2: starting CMD36 arg 012977ff flags 00000095
> [  128.640089] mmc2: starting CMD38 arg 80000000 flags 00000095
> [  128.645811] mmc2: mmc_poll_for_busy
> [  130.456184] mmc2: erase operation completes
> [  130.468390] mmc2: starting CMD35 arg 01297800 flags 00000095
> [  130.474160] mmc2: starting CMD36 arg 012993ff flags 00000095
> [  130.479928] mmc2: starting CMD38 arg 80000000 flags 00000095
> [  130.485798] mmc2: mmc_poll_for_busy
> [  132.192309] mmc2: erase operation completes
> ...
>
> Apply this patch
> [  296.480818] mmc2: starting CMD35 arg 01294000 flags 00000095
> [  296.487219] mmc2: starting CMD36 arg 01493fff flags 00000095
> [  296.492995] mmc2: starting CMD38 arg 80000000 flags 00000095
> [  296.498999] mmc2: mmc_poll_for_busy
> [  298.712865] mmc2: erase operation completes

Thanks for sharing the log, much appreciated!

Just to double check, I assume that you have verified that the
busy-polling works as expected on your HW? The reason for asking is
that we have seen problems with this several times in the past, on
other HWs.

Kind regards
Uffe

Powered by blists - more mailing lists