Message-ID:
 <DU2PR04MB8567C09C52C66C59C9CA6607EDAAA@DU2PR04MB8567.eurprd04.prod.outlook.com>
Date: Tue, 16 Dec 2025 10:02:49 +0000
From: Luke Wang <ziniu.wang_1@....com>
To: Ulf Hansson <ulf.hansson@...aro.org>
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



> -----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."

> 
> >
> > 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.

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.

> 
> 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

Regards,
Luke
> 
> Kind regards
> Uffe
> 
> >
> > ---
> > Changes in v2:
> > - Rebased on v6.19-rc1 as requested
> > - Cover letter: terminology fix (command -> operation)
> > ---
> >
> > Luke Wang (2):
> >   block: decouple secure erase size limit from discard size limit
> >   mmc: add quirk to optimize certain Kingston eMMC secure erase/trim
> >     performance
> >
> >  block/blk-merge.c         | 9 +++++++--
> >  block/blk.h               | 6 +++++-
> >  drivers/mmc/core/card.h   | 5 +++++
> >  drivers/mmc/core/queue.c  | 9 +++++++--
> >  drivers/mmc/core/quirks.h | 9 +++++++++
> >  include/linux/mmc/card.h  | 1 +
> >  6 files changed, 34 insertions(+), 5 deletions(-)
> >
> > --
> > 2.34.1
> >

Powered by blists - more mailing lists