[PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[ziniu.wang_1]

From: Luke Wang <ziniu.wang_1@nxp.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.

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.

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

[PATCH v2 1/2] block: decouple secure erase size limit from discard size limit

[ziniu.wang_1]

From: Luke Wang <ziniu.wang_1@nxp.com>

Secure erase should use max_secure_erase_sectors instead of being limited
by max_discard_sectors. Separate the handling of REQ_OP_SECURE_ERASE from
REQ_OP_DISCARD to allow each operation to use its own size limit.

Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
---
 block/blk-merge.c | 9 +++++++--
 block/blk.h       | 6 +++++-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index d3115d7469df..0885e4b982ed 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -169,8 +169,13 @@ struct bio *bio_split_discard(struct bio *bio, const struct queue_limits *lim,
 
 	granularity = max(lim->discard_granularity >> 9, 1U);
 
-	max_discard_sectors =
-		min(lim->max_discard_sectors, bio_allowed_max_sectors(lim));
+	if (bio_op(bio) == REQ_OP_SECURE_ERASE)
+		max_discard_sectors = min(lim->max_secure_erase_sectors,
+					  bio_allowed_max_sectors(lim));
+	else
+		max_discard_sectors = min(lim->max_discard_sectors,
+					  bio_allowed_max_sectors(lim));
+
 	max_discard_sectors -= max_discard_sectors % granularity;
 	if (unlikely(!max_discard_sectors))
 		return bio;
diff --git a/block/blk.h b/block/blk.h
index e4c433f62dfc..4cd5a91346d8 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -208,10 +208,14 @@ static inline unsigned int blk_queue_get_max_sectors(struct request *rq)
 	struct request_queue *q = rq->q;
 	enum req_op op = req_op(rq);
 
-	if (unlikely(op == REQ_OP_DISCARD || op == REQ_OP_SECURE_ERASE))
+	if (unlikely(op == REQ_OP_DISCARD))
 		return min(q->limits.max_discard_sectors,
 			   UINT_MAX >> SECTOR_SHIFT);
 
+	if (unlikely(op == REQ_OP_SECURE_ERASE))
+		return min(q->limits.max_secure_erase_sectors,
+			   UINT_MAX >> SECTOR_SHIFT);
+
 	if (unlikely(op == REQ_OP_WRITE_ZEROES))
 		return q->limits.max_write_zeroes_sectors;
 
-- 
2.34.1

Re: [PATCH v2 1/2] block: decouple secure erase size limit from discard size limit

[Christoph Hellwig]

> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -169,8 +169,13 @@ struct bio *bio_split_discard(struct bio *bio, const struct queue_limits *lim,
>  
>  	granularity = max(lim->discard_granularity >> 9, 1U);
>  
> -	max_discard_sectors =
> -		min(lim->max_discard_sectors, bio_allowed_max_sectors(lim));
> +	if (bio_op(bio) == REQ_OP_SECURE_ERASE)
> +		max_discard_sectors = min(lim->max_secure_erase_sectors,
> +					  bio_allowed_max_sectors(lim));
> +	else
> +		max_discard_sectors = min(lim->max_discard_sectors,
> +					  bio_allowed_max_sectors(lim));

Please factor our a low-level helper and pass the max_sectors
as argument.

[PATCH v2 2/2] mmc: add quirk to optimize certain Kingston eMMC secure erase/trim performance

[ziniu.wang_1]

From: Luke Wang <ziniu.wang_1@nxp.com>

Kingston eMMC IY2964 and IB2932 takes a fixed ~2 seconds for each secure
erase/trim operation regardless of size - that is, a single secure
erase/trim operation of 1MB takes the same time as 1GB. With default
calculated 3.5MB max discard size, secure erase 1GB requires ~300 separate
operations taking ~10 minutes total.

Add MMC_QUIRK_FIXED_SECURE_ERASE_TRIM_TIME quirk to set maximum secure
erase size for those devices. This allows 1GB secure erase to complete
in a single operation, reducing time from 10 minutes to just 2 seconds.

Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
---
 drivers/mmc/core/card.h   | 5 +++++
 drivers/mmc/core/queue.c  | 9 +++++++--
 drivers/mmc/core/quirks.h | 9 +++++++++
 include/linux/mmc/card.h  | 1 +
 4 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/card.h b/drivers/mmc/core/card.h
index 1200951bab08..0a198a2c2616 100644
--- a/drivers/mmc/core/card.h
+++ b/drivers/mmc/core/card.h
@@ -305,4 +305,9 @@ static inline int mmc_card_no_uhs_ddr50_tuning(const struct mmc_card *c)
 	return c->quirks & MMC_QUIRK_NO_UHS_DDR50_TUNING;
 }
 
+static inline int mmc_card_fixed_secure_erase_trim_time(const struct mmc_card *c)
+{
+	return c->quirks & MMC_QUIRK_FIXED_SECURE_ERASE_TRIM_TIME;
+}
+
 #endif
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 284856c8f655..eb1053d8cae7 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -184,8 +184,13 @@ static void mmc_queue_setup_discard(struct mmc_card *card,
 		return;
 
 	lim->max_hw_discard_sectors = max_discard;
-	if (mmc_card_can_secure_erase_trim(card))
-		lim->max_secure_erase_sectors = max_discard;
+	if (mmc_card_can_secure_erase_trim(card)) {
+		if (mmc_card_fixed_secure_erase_trim_time(card))
+			lim->max_secure_erase_sectors = UINT_MAX >> card->erase_shift;
+		else
+			lim->max_secure_erase_sectors = max_discard;
+	}
+
 	if (mmc_card_can_trim(card) && card->erased_byte == 0)
 		lim->max_write_zeroes_sectors = max_discard;
 
diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
index c417ed34c057..1f7406c0ab03 100644
--- a/drivers/mmc/core/quirks.h
+++ b/drivers/mmc/core/quirks.h
@@ -153,6 +153,15 @@ static const struct mmc_fixup __maybe_unused mmc_blk_fixups[] = {
 	MMC_FIXUP("M62704", CID_MANFID_KINGSTON, 0x0100, add_quirk_mmc,
 		  MMC_QUIRK_TRIM_BROKEN),
 
+	/*
+	 * On Some Kingston eMMCs, secure erase/trim time is independent
+	 * of erase size, fixed at approximately 2 seconds.
+	 */
+	MMC_FIXUP("IY2964", CID_MANFID_KINGSTON, 0x0100, add_quirk_mmc,
+		  MMC_QUIRK_FIXED_SECURE_ERASE_TRIM_TIME),
+	MMC_FIXUP("IB2932", CID_MANFID_KINGSTON, 0x0100, add_quirk_mmc,
+		  MMC_QUIRK_FIXED_SECURE_ERASE_TRIM_TIME),
+
 	END_FIXUP
 };
 
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index e9e964c20e53..1882267ef201 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -329,6 +329,7 @@ struct mmc_card {
 #define MMC_QUIRK_BROKEN_CACHE_FLUSH	(1<<16)	/* Don't flush cache until the write has occurred */
 #define MMC_QUIRK_BROKEN_SD_POWEROFF_NOTIFY	(1<<17) /* Disable broken SD poweroff notify support */
 #define MMC_QUIRK_NO_UHS_DDR50_TUNING	(1<<18) /* Disable DDR50 tuning */
+#define MMC_QUIRK_FIXED_SECURE_ERASE_TRIM_TIME	(1<<19) /* Secure erase/trim time is fixed regardless of size */
 
 	bool			written_flag;	/* Indicates eMMC has been written since power on */
 	bool			reenable_cmdq;	/* Re-enable Command Queue */
-- 
2.34.1

Re: [PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[Ulf Hansson]

On Mon, 15 Dec 2025 at 11:18, <ziniu.wang_1@nxp.com> wrote:
>
> From: Luke Wang <ziniu.wang_1@nxp.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.

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

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?

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
>

RE: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[Luke Wang]

> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@linaro.org>
> Sent: Monday, December 15, 2025 11:38 PM
> To: Luke Wang <ziniu.wang_1@nxp.com>
> Cc: axboe@kernel.dk; linux-block@vger.kernel.org; linux-
> mmc@vger.kernel.org; linux-kernel@vger.kernel.org; imx@lists.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@nxp.com> wrote:
> >
> > From: Luke Wang <ziniu.wang_1@nxp.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
> >

Re: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[Christoph Hellwig]

On Tue, Dec 16, 2025 at 10:02:49AM +0000, Luke Wang wrote:
> In fact, secure erase does not guarantee that data is physically
> erased.

It can't.  Given how Flash storage works there is no way to actually
securely erase data on a per-LBA range basis. 

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

And this is 100% correct.  Only a device-level Sanitize operation
can do meaningful erasure of data on Flash based media (or modern
HDDs with all the remapping they do for that matter).

Re: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[Ulf Hansson]

On Tue, 16 Dec 2025 at 11:02, Luke Wang <ziniu.wang_1@nxp.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Ulf Hansson <ulf.hansson@linaro.org>
> > Sent: Monday, December 15, 2025 11:38 PM
> > To: Luke Wang <ziniu.wang_1@nxp.com>
> > Cc: axboe@kernel.dk; linux-block@vger.kernel.org; linux-
> > mmc@vger.kernel.org; linux-kernel@vger.kernel.org; imx@lists.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@nxp.com> wrote:
> > >
> > > From: Luke Wang <ziniu.wang_1@nxp.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